[Gc] Re[34]: GC + Windows Mobile + Threads + Patch for WINCE

Ivan Maidanski ivmai at mail.ru
Sun Oct 18 09:10:51 PDT 2009


Hi!
Zeyi Lee <biosli at hotmail.com> wrote:
> Dear Ivan:
> > I've changed the allocation routines (this minimizes overflow of heap sections), so it's crucial to retest case 1 again (with 64K stack).
> I've downloaded the version at 09/09/17 in CVS. And I test the original edition, only defined VERY_SMALL_CONFIG.
> The output as below:
> ----------------------
> Received WM_CLOSE, closing window
> ...
> Total number of bytes allocated is 21653080
> Final heap size is 17555456 bytes
> Unexpected heap growth - collector may be broken
> Collector appears to work
> ----------------------
> Is the output with "Unexpected heap growth - collector may be broken" means the collector could not work?

I believe this doesn't imply the GC is broken - the message printed because the corresponding assert condition is too restrictive (I had tried to relax it a little but failed, so I leave it as-is).

> > Please fetch latest CVS and apply ivmai143.diff (http://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3213)
>
>
> I retest the program with your patch(ivmai143.diff), the test output as following:
> ---------------------
> ...
> Collector appears to work
> ---------------------

Thanks but I've decided to drop that patch because it lacks memory reservation (for WinCE).

I've also added run-time detection of the memory model to use recenly, so if you want to test, fetch the latest CVS.

> > Plus also add -DMAKE_BACK_GRAPH (if this wouldn't result in out-ot-mem).
> I retest Case 1(stack = 65536, with VERY_SMALL_CONFIG, MAKE_BACK_GRAPH).
> The program crashed and I get a DebugBreak, output as below:
> --------------------
> Collecting from unknown thread.
> --------------------

Interesting (I haven't observed it on my device), could you tell me the backtrace (call graph) of that DebugBreak?

> Best Wishes,
> Zeyi Lee

Bye.


More information about the Gc mailing list