This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Garbage Collector Issues on Win98/gcj 4.02
- From: Tom Tromey <tromey at redhat dot com>
- To: Mohan Embar <gnustuff at thisiscool dot com>
- Cc: java at gcc dot gnu dot org
- Date: 23 May 2006 18:51:50 -0600
- Subject: Re: Garbage Collector Issues on Win98/gcj 4.02
- References: <DC61RL623XMJA81T95GBTP96UT652ZTR.44736208@d9300>
- Reply-to: tromey at redhat dot com
>>>>> "Mohan" == Mohan Embar <gnustuff@thisiscool.com> writes:
> void
> java::lang::Class::finalize (void)
> {
> engine->unregister(this);
> }
Mohan> In any case, when this method is
Mohan> called "engine" is still null, so we choke here.
Oops! We neglected to ever set an engine for array classes, and
never noticed because they are born with state==JV_STATE_DONE.
Mohan> I (probably naively) changed the above to
Mohan> if (engine) engine->unregister(this)
I think this would be ok, provided there's a comment explaining why.
Another idea is to add a new execution engine where all the methods
do nothing, and then use this for arrays. But I think the above is
actually a bit more maintainable -- if we ever did need an engine for
arrays, it would be better to have the linker and whatnot just SEGV
instead of silently doing nothing.
Thoughts?
As to the bigger problem... I would not expect any classes to be
collected during startup. I think that is wrong. Maybe something is
not being marked correctly by the GC?
You could see exactly what class is being GCd in the debugger... you
can look at class->name or class->element_type->name.
Mohan> The next horrible thing that happens is in this
Mohan> call in _Jv_NewStringUtf8Const (natString.cc):
[...]
Mohan> Just wanted to throw this over the wall in case it rings a
Mohan> bell with anyone.
This latter one I don't know about.
Tom