[Gc] Re: GC + Windows Mobile + Threads + Patch for WINCE
ivmai at mail.ru
Thu Sep 17 02:23:16 PDT 2009
Zeyi Lee <biosli at hotmail.com> wrote:
> Ivan wrote:
> > Interesting to retry the "case 1" test:
> > 1. with /link /stack:32768 (or with a 64K stack if 32K fails);
> with /link /stack:65536 success, output as following:
> Completed 6 tests
> Total number of bytes allocated is 24081266
> Final heap size is 3268608 bytes
> Collector appears to work
I've changed the allocation routines (this minimizes overflow of heap sections), so it's crucial to retest case 1 again (with 64K stack).
Please fetch latest CVS and apply ivmai143.diff (https://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3213)
Plus also add -DMAKE_BACK_GRAPH (if this wouldn't result in out-ot-mem).
> > 2. if success: the same stack param but without -DVERY_SMALL_CONFIG.
> stack = 65536, I get output:
> GC Warning: Out of Memory! Returning NIL!
> Out of memory
It's interested to retest (of course, if case 1 succeeds) this too (just to see what heap size value is printed in "GC Warning").
> > BTW. What is your _M_ARM value your are compiling for?
> Sorry, I don't know what your meaning currently.
> My project defined ARM and _ARM_ without any value.
> Is it that you want?
No. _M_ARM is a predefined macro, it's controlled by VC++ /QRarch<n> option (if you (or your IDE) specify none then the default is /QRarch4 (_M_ARM = 4). I'm asking for it because pre-ARM6 and ARM6+ CPUs are handled differently in libatomic_ops (arm.h).
More information about the Gc