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

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Fri, 30 Jan 2004 11:36:41 -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 derek.mcumber@datamtnsol.com.


--- 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
+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
+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.