velocity-user mailing list archives

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

> on 9/9/01 4:38 PM, "Geir Magnusson Jr." <geirm@optonline.net> wrote:
> 
>> On 9/9/01 12:36 PM, "Paulo Gaspar" <paulo.gaspar@krankikom.de> 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

-- 
Geir Magnusson Jr.     geirm@optonline.net
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
If you look up, there are no limits - Japanese Proverb


Mime
View raw message