Longevity of static class variables in Applet JVM

[Richard Maher]

Hi,

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]

Hi Mark,

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.

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,



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.

I see.


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!".


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?

 

[Roedy Green]

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]

Hi Roedy,

Thanks for the reply.

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]

Hi again,

Hi Roedy,

Thanks for the reply.

EDT

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

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
delivered, are we still all good to go with "It just get's [sic] delivered in the
EDT"? Which Java version of the JVM is running in the EDT?

Whatever the configured JVM is for the applet environment (browser,
Appletviewer, ...).

 

[Richard Maher]

Hi 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
delivered, are we still all good to go with "It just get's [sic] delivered in the
EDT"? Which Java version of the JVM is running in the EDT?

Whatever the configured JVM is for the applet environment (browser,
Appletviewer, ...).

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

Cheers Richard Maher