[Mono-bugs] [Bug 53177][Nor] Changed - WaitHandles are not finalizing

[bugzilla-daemon@bugzilla.ximian.com]

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 derek.mcumber@datamtnsol.com.

http://bugzilla.ximian.com/show_bug.cgi?id=53177

--- 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 @@
 Bug#: 53177
 Product: Mono/Runtime
 Version: unspecified
 OS: unknown
 OS Details: 
-Status: REOPENED   
+Status: NEEDINFO   
 Resolution: 
 Severity: Unknown
 Priority: Normal
 Component: misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: derek.mcumber@datamtnsol.com               
@@ -530,6 +530,72 @@
 
 My current assessment is that with fairly high probability, you are
 really seeing
 Mono issues, and not something I can address.
 
 Hans
+
+------- Additional Comments From derek.mcumber@datamtnsol.com  2004-01-31 00:30 -------
+More from Derek and Hans Boehm:
+
+DEREK>>>
+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? 
+>>>>
+
+HANS>>>
+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
+unfortunate
+property that when you interpret it as integers or pointers, it's
+pretty uniformly
+distributed.  Hence on a 32 bit machine, if you have 4 MB of
+compressed data
+in the heap, and the collector scans it, it will appear as 1 million
+uniformly
+distributed pointers to every part of the address space.  The average
+"hole"
+between these false pointer references will be 4KB, making it hard to
+allocate
+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
+contain
+pointers, and hence should not be scanned.  Presumably compressed data
+is stored
+in an array of integers or bytes.  My reading of the Mono code is that
+it already
+tries to tell the collector that such data should not be scanned. 
+(There may
+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
+sufficiently
+recent Mono version that it should be working).
+
+If you don't mind, we should really get the Mono developers involved
+in this
+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
+effectively do
+by setting the ignore_off_page flag).
+
+Hans