velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: performance questions
Date Mon, 10 Sep 2001 06:11:12 GMT
On 9/9/01 1:54 PM, "Jon Stevens" <> wrote:

> on 9/9/01 4:38 PM, "Geir Magnusson Jr." <> wrote:
>> On 9/9/01 12:36 PM, "Paulo Gaspar" <> wrote:
>>> According to the Java spec (yes, I was really reading the class loading
>>> part a couple of weeks ago) it is JUST like Jon says.
>>> Which in turn means: it does not matter if it is a singleton or not.
>>> A different class loader is a bit like a different universe, unless one
>>> is parent/ancestor of the other.
>> So you have some singleton instance of something that is happily off doing
>> work, say with a few threads...
>> Then you dump the classloader that created it.
>> The JVM then instantly destroy's every object created by that classloader??
>> Yikes.
>> How do you catch this to do cleanup?
> Implement:
>   public void destroy()
>   {
>   }
>> I believe you all, but first, it goes against my (broken) mental model which
>> I will fix :) , and two, it's horribly frightening to think that in the
>> normal course of business, a living object gets automatically destroyed
>> arbitrarily because the classloader changed.
> The CL doesn't get 'changed', it gets nullified and a new one is created to
> replace the previous one. :-)

Obviously not 'changed', like it wet itself or something... :)

> It is then the new CL's job to load whatever
> classes it is requested to load. CL's also don't cache the instances to the
> objects...instead...
> The issue is that each Object has an internal reference to the CL that
> created it. If that CL becomes invalid, then you get all sorts of nasty
> exceptions if you try to use that Object in any way.
> Therefore, you must make certain that access to ALL of those Objects is not
> given. You also have to make sure that each of those objects is removed in
> order to remove all references to the previous CL in order to allow for that
> CL to get GC'd.

So how does it work for singletons?  I assume that the classloader then has
to keep the reference, and if that singleton is doing work (oh, say,
controlling the flaps on a landing :), then something special has to be done
rather than just punting and letting it get GC'd, as you don't want two of
those flap-controlling singletons working at the same time...
>> I guess you have to be really
>> careful with classloader interaction in critical systems.
> Without a doubt.
> CL's are one of the most important, most complex, least understood and most
> poorly designed parts of the Java Language. :-)

I am starting to think +1 on that 'poorly designed' bit...  Maybe, to be
generous, we can say 'horribly abused'...


Geir Magnusson Jr.
System and Software Consulting
Developing for the web?  See
If you look up, there are no limits - Japanese Proverb

View raw message