Porting Boehm-gc to embedded m68k environment

Wed Nov 5 21:36:00 GMT 2003

It could use GC_malloc_atomic_uncollectable() instead. On Linux it probably
doesn't make much difference. There are arguments both ways.
On win32, GC_malloc_atomic_uncollectable() might actually be preferable,
since the collector needs to use a heuristic to avoid the tracing the
system malloc heap (at least until it gets more information about root locations).
It can reliably avoid tracing objects allocated with GC_malloc_atomic_uncollectable(),
since it has accurate information about them.
Hans
> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> David Daney
> Sent: Tuesday, November 04, 2003 10:06 PM
> To: John Neil
> Cc: java@gcc.gnu.org
> Subject: Re: Porting Boehm-gc to embedded m68k environment
>>> John Neil wrote:
>> >3. Why do the Jv_realloc and Jv_malloc functions in prims.cc us
> >realloc/malloc directly rather than the corresponding GC function's
> >GC_malloc/GC_alloc. Is this for efficiency reasons, to 
> reduce the amount of
> >memory the GC has to scan during a collection.
> >
> Jv_malloc et. al. are used to allocate non-garbage-collected 
> memory. So by definition you cannot used GCed memory for this.
>> They are used by the parts of the runtime need to explicitly 
> manage their own memory. The support for soft and weak 
> references uses it. And there are surely other parts of the 
> runtime that need it as well.
>> David Daney.
>>>>