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: Mohan Embar <gnustuff at thisiscool dot com>
- To: tromey at redhat dot com
- Cc: java at gcc dot gnu dot org
- Date: Tue, 23 May 2006 21:02:48 -0500
- Subject: Re: Garbage Collector Issues on Win98/gcj 4.02
Hi Tom,
>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.
What are the consequences of these being born with state==JV_STATE_DONE?
Does this mean they shouldn't be collected?
>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?
I'm not quite clear on what you're proposing here. Are you saying that
it would be better to:
- leave it as engine->unregister(this) and allow for a SEGV?
- conditionalize this with "if (engine)"?
- add a new execution engine for arrays?
I have just a vague idea of what's going on here, so I don't feel
qualified to form an opinion yet....
>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.
I did this and had a list, but it got lost amidst a bunch of other changes.
I'll dig this up again and post it.
-- Mohan Embar
http://www.thisiscool.com/
http://www.animalsong.org/