Questions about GC, _Jv_MarkObj() and reflection data.

[Andrew Haley]

David Daney writes:
 > Andrew Haley wrote:
 > > David Daney writes:
 > >  > I think my patch for removing most reflection data is almost working 
 > >  > (yeah!).
 > >  > 
 > >  > My last problem seems to be with classes that use _Jv_MarkObj(). 
 > >  > Currently I emit no reflection data for non-static fields.  However this 
 > >  > does not work if the GC descriptor has a value of 2 (which appears to 
 > >  > mean to use _Jv_MarkObj()), as _Jv_MarkObj uses the field reflection 
 > >  > data to tell if a field contains a reference.
 > >  > 
 > >  > Lets just say I was a little mystified until I realized the GC was 
 > >  > freeing referenced objects and allocating objects of a different type in 
 > >  > their place.
 > >  > 
 > >  > The obvious solution is to generate reflection data for non-static 
 > >  > fields that contain references.  But I wanted to do a sanity check 
 > >  > before proceeding.
 > > 
 > > Well, all you *really* need is a bitmap, but OK.
 > 
 > *If* that were true, then why does _Jv_MarkObj() exist?

 > Most classes *do* use a bitmap, on those that do not I had this
 > problem.

That's because bitmap marking is currently limited to classes with
fewer than N fields.  But there's nothing to stop you defining a
different kind of bitmap (a "long bitmap") and teaching _Jv_MarkObj()
how to use it.  But it's easier to go with reflection data, I'm sure.

Andrew.