[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:35:35.000000000 -0500
+++ shadow/53177.tmp.23533	2004-01-30 11:36:41.000000000 -0500
@@ -470,6 +470,66 @@
 stay tuned.
 
 ------- Additional Comments From derek.mcumber@datamtnsol.com  2004-01-26 23:15 -------
 Created an attachment (id=6526)
 Here is a minimum number of changes plus some GC_PRINT_STAT statements to follow what is happening.  I mispoke earlier when I said I was using gcc.  I was using msft vc7.
 
+
+------- Additional Comments From derek.mcumber@datamtnsol.com  2004-01-30 11:36 -------
+From Hans Boehm=>
+
+Unfortunately, I can't really run code like this behind the HP firewall.
+I might be able to do it from home.  (Should this work on WinME?)
+
+Did you try asking about this on the Mono mailing list?
+
+Based on the log files you sent, there appear to be two problems,
+which may
+be unrelated:
+
+1) The collector is seeing too many false pointers, causing it to
+blacklist the
+pages they point to, and making it difficult for it to find anyplace
+to allocate
+new pages.  This is causing the heap growth.  (I think a call to
+GC_dump() late
+in the execution would confirm this.  The messages about "very large"
+objects which turn
+out not to be that big are very suggestive, as it stands.)
+
+This is almost certainly due to the collector getting insufficient
+type information,
+which it presumably needs since you have a bunch of compressed data in
+the heap,
+which looks random.  And I can reproduce logs similar to this aspect
+of your
+log with a simple test program that has similar characteristics.
+
+My reading of the Mono code is that recent versions (last few months
+at least)
+should give the collector enough type information that this shouldn't
+be an issue.
+Again GC_dump() output could partially confirm that's working.
+
+Setting the ignore_off_page flag in your patch largely circumvents
+this problem,
+but that's not a great solution.
+
+2) Your logs indicate that garbage collections often happen in rapid
+succession,
+sometimes with no allocation between collections.  I can't reproduce
+this in isolation.
+But I note that Mono contains explicit GC_gcollect() calls.  I
+normally consider those
+somewhat suspect.  It would be good to know what the call stack looks
+like for those
+collector invocations.  (I think your Sleep() calls may avoid some of
+these.)
+
+I would expect this to primarily slow things down.  I think (1) is the
+main problem.
+
+My current assessment is that with fairly high probability, you are
+really seeing
+Mono issues, and not something I can address.
+
+Hans