Longevity of static class variables in Applet JVM
Richard Maher
I have read the recent "garbage collection" and "persistent object" threads
here in cljp and have a related, yet different, question(s) that I hope some
people can help me with. (My interest/focus is strictly to do with Applets
right now, and am quite happy for everything to disappear ( +/- finalize() )
when the JVM and browser instance dies.)
Are static class variables once referenced in an Applet ever candidates for
garbage-collection in a JVM, specifically when there are no longer any
active Applets currently referencing them? (That is, the page that loaded
the Applet, the JVM, and the class with the class-variables, has long since
gone.) IOW, is the reference to these static class variables held by the
class-loading JVM itself rather than by each Applet? Furthermore, that they
will persist as long as the JVM persists?
If events are then delivered on such static objects (once again, sometime
after the last Applet/ web-page to have referenced them has long gone) what
thread is the event delivered in? (I'm guessing the standard browser EDT but
the Java 6 reorg with Applet threads has me doubting it)
Cheers Richard Maher
Mark Space
> Are static class variables once referenced in an Applet ever candidates for
> garbage-collection in a JVM, specifically when there are no longer any
> active Applets currently referencing them? (That is, the page that loaded
Yes, all objects, including static ones and classes, are available for
garbages collection once they are no longer referenced.
How exactly a browser handles this, I have no idea.
> If events are then delivered on such static objects (once again, sometime
> after the last Applet/ web-page to have referenced them has long gone) what
> thread is the event delivered in? (I'm guessing the standard browser EDT but
> the Java 6 reorg with Applet threads has me doubting it)
You have to be holding a refernce to a class to get events related to
it, so in that case it couldn't be garbage collected. Also, Swing and
AWT don't deliver any sort of GC events, ever. You're pretty confused.
You might be able to get some info by keeping phantom references to
objects around. The queue associated with the phantom reference will
receive events when the object is gc'd.
It might be even easier however to just connect a debugger or profiler,
and observe which objects are gc'd and when.
Richard Maher
"Mark Space" <mark...@sbc.global.net> wrote in message
news:z86Ml.32662$ZP4....@nlpi067.nbdc.sbc.com...
> Richard Maher wrote:
>
> > Are static class variables once referenced in an Applet ever candidates
for
> > garbage-collection in a JVM, specifically when there are no longer any
> > active Applets currently referencing them? (That is, the page that
loaded
>
>
> Yes, all objects, including static ones and classes, are available for
> garbages collection once they are no longer referenced.
Really? So sometimes (pre-GC run) when I return to the page with the Applet,
I'll see things as they were when I was last there (eg: invocationCounter,
runningTotal) and other times they will be recreated afresh, even though
it's the same JVM? Doesn't sound very deterministic :-(
But it looks like this person disagrees with you: -
http://forums-beta.sun.com/thread.jspa?messageID=513241
Are you saying "the life of the program" referred to in that thread is the
life of the Applet rather than the life of the Classloader/JVM/Browser?
Maybe someone else with experience of such things can chime in?
> How exactly a browser handles this, I have no idea.
I see.
>
> > If events are then delivered on such static objects (once again,
sometime
> > after the last Applet/ web-page to have referenced them has long gone)
what
> > thread is the event delivered in? (I'm guessing the standard browser EDT
but
> > the Java 6 reorg with Applet threads has me doubting it)
>
>
> You have to be holding a refernce to a class to get events related to
> it, so in that case it couldn't be garbage collected. Also, Swing and
> AWT don't deliver any sort of GC events, ever. You're pretty confused.
Perhaps, there appears to be a lot of it about :-(
Not sure what the "GC events" you refer to are and I'm not really
interested, I was thinking more along the lines of something that implements
ActionListener.
But as colourful inflammatory accusations seem to be de rigueur at cljp
let's leave it at "You're talking bollocks!".
> You might be able to get some info by keeping phantom references to
> objects around. The queue associated with the phantom reference will
> receive events when the object is gc'd.
>
> It might be even easier however to just connect a debugger or profiler,
> and observe which objects are gc'd and when.
>
Hmmm.
>
Regards Richard Maher
Knute Johnson
> Hi Mark,
>
> "Mark Space" <mark...@sbc.global.net> wrote in message
> news:z86Ml.32662$ZP4....@nlpi067.nbdc.sbc.com...
>> Richard Maher wrote:
>>
>>> Are static class variables once referenced in an Applet ever candidates
> for
>>> garbage-collection in a JVM, specifically when there are no longer any
>>> active Applets currently referencing them? (That is, the page that
> loaded
>>
>> Yes, all objects, including static ones and classes, are available for
>> garbages collection once they are no longer referenced.
>
> Really? So sometimes (pre-GC run) when I return to the page with the Applet,
> I'll see things as they were when I was last there (eg: invocationCounter,
> runningTotal) and other times they will be recreated afresh, even though
> it's the same JVM? Doesn't sound very deterministic :-(
>
> But it looks like this person disagrees with you: -
> http://forums-beta.sun.com/thread.jspa?messageID=513241
> Are you saying "the life of the program" referred to in that thread is the
> life of the Applet rather than the life of the Classloader/JVM/Browser?
>
> Maybe someone else with experience of such things can chime in?
I don't think that article conflicts with what Mark said. Objects
referenced by static class variables are going to be destroyed when the
JVM unloads.
>> How exactly a browser handles this, I have no idea.
>
> I see.
>
>>> If events are then delivered on such static objects (once again,
> sometime
>>> after the last Applet/ web-page to have referenced them has long gone)
> what
>>> thread is the event delivered in? (I'm guessing the standard browser EDT
> but
>>> the Java 6 reorg with Applet threads has me doubting it)
>>
>> You have to be holding a refernce to a class to get events related to
>> it, so in that case it couldn't be garbage collected. Also, Swing and
>> AWT don't deliver any sort of GC events, ever. You're pretty confused.
>
> Perhaps, there appears to be a lot of it about :-(
>
> Not sure what the "GC events" you refer to are and I'm not really
> interested, I was thinking more along the lines of something that implements
> ActionListener.
>
> But as colourful inflammatory accusations seem to be de rigueur at cljp
> let's leave it at "You're talking bollocks!".
>
>> You might be able to get some info by keeping phantom references to
>> objects around. The queue associated with the phantom reference will
>> receive events when the object is gc'd.
>>
>> It might be even easier however to just connect a debugger or profiler,
>> and observe which objects are gc'd and when.
>>
>
> Hmmm.
A lot of that depends on the JVM that is running and on the browser.
There are JVMs that never call stop() or unload when the browser moves off.
The real question though is why do you care? Is there something special
you are trying to accomplish?
--
Knute Johnson
email s/nospam/knute2009/
--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
Roedy Green
<mahe...@hotspamnotmail.com> wrote, quoted or indirectly quoted
someone who said :
>If events are then delivered on such static objects (once again, sometime
>after the last Applet/ web-page to have referenced them has long gone) what
>thread is the event delivered in? (I'm guessing the standard browser EDT but
>the Java 6 reorg with Applet threads has me doubting it)
Applets use an EDT thread that most of the work happens on. You share
that same EDT thread with all the other applets. So there is even
more reason than usual not to dawdle in event handling.
I think the browser is free to do what it wants but the intent is it
will call stop when you applet is scrolled off screen, start when it
is scrolled back on again and destroy when the user leaves the page.
--
Roedy Green Canadian Mind Products
http://mindprod.com
"It wasn�t the Exxon Valdez captain�s driving that caused the Alaskan oil spill. It was yours."
~ Greenpeace advertisement New York Times 1990-02-25
Richard Maher
Thanks for the reply.
"Roedy Green" <see_w...@mindprod.com.invalid> wrote in message
news:jlkg05dro6ss0uoim...@4ax.com...
> uOn Wed, 6 May 2009 09:21:01 +0800, "Richard Maher"
> <mahe...@hotspamnotmail.com> wrote, quoted or indirectly quoted
> someone who said :
>
> >If events are then delivered on such static objects (once again, sometime
> >after the last Applet/ web-page to have referenced them has long gone)
what
> >thread is the event delivered in? (I'm guessing the standard browser EDT
but
> >the Java 6 reorg with Applet threads has me doubting it)
>
> Applets use an EDT thread that most of the work happens on. You share
> that same EDT thread with all the other applets. So there is even
> more reason than usual not to dawdle in event handling.
That's what I thought, but with the Java 6 mutiple thread infrastructure to
support multi-version JVMing I had/have some doubts that the EDT was still
the only game in town. (With init() sometimes yeilding it's block on
JavaScript half-way through, everything could be on the table :-)
Regards Richard Maher
Richard Maher
"Richard Maher" <mahe...@hotspamnotmail.com> wrote in message
news:guae13$in3$1...@news-01.bur.connect.com.au...
Just found this link as well: -
https://jdk6.dev.java.net/plugin2/
Full of good stuff related to this thread, in particular the discussion on
the new "classloader_cache" parameter and how it defaults to "true". All
good stuff!
But if each applet now has it's own thread and, for example, Applet1
instantiated a static class variable that has an event listener on it then
the page that defined/created Applet1 is replaced before the event is
delivered, are we still all good to go with "It just get's delivered in the
EDT"? Which Java version of the JVM is running in the EDT?
Anyway, I guess that the best way to find out is to give it a go and see
what happens.
Cheers Richard Maher
Lew
> But if each applet now has it's [sic] own thread and, for example, Applet1
> instantiated a static class variable that has an event listener on it then
> the page that defined/created Applet1 is replaced before the event is
> EDT"? Which Java version of the JVM is running in the EDT?
Whatever the configured JVM is for the applet environment (browser,
Appletviewer, ...).
--
Lew
Richard Maher
"Lew" <no...@lewscanon.com> wrote in message
news:guajum$gik$1...@news.albasani.net...
So would the following be a reasonable interpretation: -
1) Pre Java 6, there was one EDT that was shared/contested between Java and
JavaScript with implicit blocking/synchronization
2) Post Java 6, with any number of JVMs running concurrently in a browser
instance whether or not for a given page (different Java versions, and that
lovely "I demand my exclusive JVM for this Applet" flag) there can be many
EDTs (1 per JVM + 1 for JavaScript?) and LiveConnect now does much extra
magic behind the scenes for synchronization with the JavaScript EDT
>
> --
> Lew
Cheers Richard Maher