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

Ivan Maidanski ivmai at mail.ru
Thu Sep 17 02:23:16 PDT 2009


Zeyi Lee <biosli at hotmail.com> wrote:
> Hi!
> 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 mailing list