RE: overhead of reflection info

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

Are we talking about the same thing here?  I think Tom and I were talking
about instances of class Class, and things hanging from it.  It would make sense to me
that that's scanned conservatively (as part of the root set) for compiled
classes.

For anything that's statically allocated, the collector won't normally see
the bitmap, even if it's there.

Hans


> -----Original Message-----
> From: Andrew Haley [mailto:aph@redhat.com]
> Sent: Wednesday, February 25, 2004 10:46 AM
> To: Jeff Sturm
> Cc: Tom Tromey; Boehm, Hans; Adam Megacz; java@gcc.gnu.org
> Subject: Re: overhead of reflection info
> 
> 
> Jeff Sturm writes:
>  > On 25 Feb 2004, Tom Tromey wrote:
>  > > >>>>> "Hans" == Boehm, Hans <hans.boehm@hp.com> writes:
>  > >
>  > > Hans> There is a claim in _Jv_MarkObj comments that some data
>  > > Hans> structures referenced from class objects are allocated
>  > > Hans> pointerfree (even though they are not?) but then traced
>  > > Hans> correctly by _Jv_MarkObj.  If this is indeed still 
> correct, this
>  > > Hans> would have to be looked at carefully.
>  > >
>  > > Oh, yeah -- _Jv_MarkObj is always used for Class objects.
>  > 
>  > But only classes loaded from bytecode, right?  Those might 
> not matter for
>  > a minimal runtime stripped of reflection info, interpreter, etc.
>  > 
>  > I think compiled classes are still traced conservatively.
> 
> No they're not -- the bitmap is generated by the compiler.  See
> mark_reference_fields() in java/boehm.c.
> 
> Andrew.
>