RE: Porting Boehm-gc to embedded m68k environment

["Boehm, Hans" <hans_boehm at hp dot com>]

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