[Mono-bugs] [Bug 53177][Nor] Changed - WaitHandles are not finalizing
Sat, 31 Jan 2004 00:30:17 -0500 (EST)
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by firstname.lastname@example.org.
--- shadow/53177 2004-01-30 11:36:41.000000000 -0500
+++ shadow/53177.tmp.29766 2004-01-31 00:30:17.000000000 -0500
@@ -1,12 +1,12 @@
@@ -530,6 +530,72 @@
My current assessment is that with fairly high probability, you are
Mono issues, and not something I can address.
+------- Additional Comments From email@example.com 2004-01-31 00:30 -------
+More from Derek and Hans Boehm:
+Your comment about the false pointers makes sense. When it adds heap
+in the while loop, i see it calling GC_allochblk which loops through
+the GC_allochblk_nth and will loop through a completely new and
+supposedly empty block and come back saying it needs more heap because
+it is 'full'.
+How can I blank out new heaps to not do this? On Windows98 it will loop
+through and lock up the OS bacause it cannot find good memory and cannot
+get out of the while loop in malloc.c.
+You will see this if WindowsME is similar.
+Any thoughts on how to fix this?
+I don't think this is an issue with fresh heap blocks. My impression
+(and perhaps I misunderstood that) is that your web server manipulates or
+generates compressed (or encrypted?) data. Compressed data has the
+property that when you interpret it as integers or pointers, it's
+distributed. Hence on a 32 bit machine, if you have 4 MB of
+in the heap, and the collector scans it, it will appear as 1 million
+distributed pointers to every part of the address space. The average
+between these false pointer references will be 4KB, making it hard to
+a 20KB objects that does not appear to be referenced by one of these.
+The solution is to let the GC know that the compressed data does not
+pointers, and hence should not be scanned. Presumably compressed data
+in an array of integers or bytes. My reading of the Mono code is that
+tries to tell the collector that such data should not be scanned.
+be an exception for pointer-sized integers, which may be getting in
+the way here.)
+My guess is that this isn't working correctly (assuming you have a
+recent Mono version that it should be working).
+If you don't mind, we should really get the Mono developers involved
+discussion, since this part is their code, not mine. Even if there
+isn't an obvious
+fix at their end, other solutions require input from them. For
+example, I suspect
+that Mono is more sensitive to this kind of problem than gcj since
+pointers into the
+interior of objects have to be recognized. But I don't know whether
+that is always
+true, or whether there might be some way to limit this (as you
+by setting the ignore_off_page flag).