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.
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org]On Behalf Of
> David Daney
> Sent: Tuesday, November 04, 2003 10:06 PM
> To: John Neil
> Cc: email@example.com
> 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.
More information about the Java