aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/OpenSim/Framework/ThreadTracker.cs
diff options
context:
space:
mode:
authorDr Scofield2009-06-03 12:39:44 +0000
committerDr Scofield2009-06-03 12:39:44 +0000
commit074b66ddcf5297ded473e8b275f77303c13fa5f1 (patch)
tree221891cc32a953bdd91edb141fa2b5df63d2d89c /OpenSim/Framework/ThreadTracker.cs
parentFrom: Alan Webb <alan_webb@us.ibm.com> (diff)
downloadopensim-SC-074b66ddcf5297ded473e8b275f77303c13fa5f1.zip
opensim-SC-074b66ddcf5297ded473e8b275f77303c13fa5f1.tar.gz
opensim-SC-074b66ddcf5297ded473e8b275f77303c13fa5f1.tar.bz2
opensim-SC-074b66ddcf5297ded473e8b275f77303c13fa5f1.tar.xz
From: Chris Yeoh <yeohc@au1.ibm.com>
- fixes wild swings in memory usage related to usage of GetDrawStringSize() We've been seeing wild swings in memory usage and a large chunk of memory leak. From analysing this it's pretty clear that the mono garbage collector is rather buggy! When exercised heavily it looks like it frees more than its meant to resulting in crashes. GetDrawStringSize() measures the size in pixels of text. To do this memory for an image is allocated and used to call the GDI text measure functions. Although no reference to the temporary memory for the measuring is kept, it takes quite a while for the mono garbage collector to clean up - so if lots calls to GetDrawStringSize() are made at once there can be a spike in memory usage. If the garbage collector is not fast enough then the GDI layer runs out of memory. It also looks like the garbage collector is not always reclaiming all of the memory. I've attached an OpenSim patch which works around the garbage collector issues. Instead of dynamically allocating memory for measuring text sizes, it serialises (on a per region basis) access to a single block of memory. The effect of this is to be nicer to the garbage collector as it has a lot less work to do, at the cost of some theoretical loss in performance (nothing noticeable with our tests which hit it pretty hard). OpenSim still does leak memory slowly, but it is a lot more stable with this patch. I suspect that either the garbage collector misses bits of freed memory or the GDI/cairo layer leaks a bit each time a texture is created. Thats going to be a lot harder to hunt down, but for reference if someone has OpenSim running on Windows it would be interesting to see if it has the same problem as it would tell us if its a mono/GDI problem or an OpenSim problem.
Diffstat (limited to 'OpenSim/Framework/ThreadTracker.cs')
0 files changed, 0 insertions, 0 deletions