RE: GC problem

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

I think this is a dangerous practice anyway.  If such objects were
ever collected, there might also be a problem at the other end, if the
containing object becomes unreachable first.

Each collected object should normally have a correct mark descriptor,
and not rely on special scanning by its parent's mark procedure.

I'm not sure I fully understand the data structure here.  Are we really
tracing from every nth field in the array?  It probably makes sense
to introduce a new GC "kind" for constant pools, with a suitable mark
procedure.  I think this should become considerably easier with the
GC_DEBUG patch I posted earlier.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Anthony Green
> Sent: Friday, July 09, 2004 1:16 AM
> To: java@gcc.gnu.org
> Subject: GC problem
> 
> 
> I've hit what looks like a GC problem while loading many classes with
> the interpreter.
> 
> In scanning over the code, I think I've found the problem.  My fear is
> that there's a window of opportunity for data in the constant pool to
> get collected while preparing interpreted classes.  
> 
> An important array is allocated in 
> _Jv_ClassReader::handleConstantPool:
> 
>   // the pool is scanned explicitly by the collector
>   jbyte *pool_tags = (jbyte*) _Jv_AllocBytes (pool_count);
>   _Jv_word *pool_data
>     = (_Jv_word*) _Jv_AllocBytes (pool_count * sizeof (_Jv_word));
> 
> It gets assigned to _Jv_ClassReader::def for a while, and then
> eventually stuffed into a proper class object, with the the GC header
> and vtable that would enable correct explicit scanning. 
> 
> It seems that I've triggered a GC run between these two events, and
> elements in my array are getting collected.  In particular, 
> UTF8 objects
> allocated like so are being written over...
> 
>       pool_data[index].utf8 = _Jv_makeUtf8Const (buffer, len);
> 
> Does this make sense?
> 
> AG
> 
> -- 
> Anthony Green <green@redhat.com>
> Red Hat, Inc.
>