RE: URLClassLoader update

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

This may be unrelated to this test case.

In my opinion, the JLS has some defects surrounding the specification of when finalizers may be run.  I read it to mean that finalizers may be run "before" the last use of a field in a structure (e.g. because the optimizer decided to move the load of that field value out of a loop).  Others disagree with that interpretation.  In any case, I doubt that any two JVMs agree.

If you're seeing an access to a previously collected object, that's a bug.  If you see a finalizer run before the last time an object is used for synchronization, that's a bug.  (Actually, it isn't, according to the spec.  But I claim that any JVM that does this is unusable.)  If you see a finalizer run before someone though the object should have been dead, I'll blame it on the (absence of a) spec for now.

Hans

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Monday, December 02, 2002 8:27 PM
> To: Mark Wielaard
> Cc: java-patches@gcc.gnu.org
> Subject: Re: URLClassLoader update
> 
> 
> >>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:
> 
> Mark> Note that the TestEarlyGC failure is not a regression 
> on powerpc.
> 
> Nor on x86.
> 
> Mark> I would still like to see the actual TestEarlyGC source 
> code though.
> 
> As I recall, it is a very simple class (you could write the byte
> values to a file and use jcf-dump if you want to see how simple).
> The problem isn't in the bytecode, the problem is that somehow the GC
> forgets about an interpreted class.
> 
> Mark> But this seems to be a bug in ResourceBundle which 
> caches results
> Mark> according to the ClassLoader used but doesn't take into 
> account that the
> Mark> requested or default) Locale can change. I will look into this.
> 
> Thanks.
> 
> Tom
>