Java AWT, Swing, threads, anon classes, and garbage collection

[David Holmes]

Hi,

On 28/11/2018 2:24 am, Ludwig, Mark wrote:
> Greetings,
> 
> Abstract:
> 
> I'd appreciate pointers to any papers or discussions about how anonymous classes are garbage-collected in current JVMs (Java 9+).
> Hopefully someone will respond that the historical problem with garbage collection of anonymous classes has been solved.

Do you mean the instances of the anonymous classes? As Michael Rasmussen 
points out these are just regular objects and GC'd like any other object.

That said it is possible there may been issues with memory leaks in the 
past with respect to AWTSwing event handlers - you'd need to ask the GUI 
folk on awt-dev or swing-dev about that.

The perm gen was removed a number of releases ago so we no longer have a 
pre-defined upper bound on what can be contained there. But as the name 
suggests that was for things which had a lifetime that matches that of 
the VM itself. If you are having issues with class unloading (or lack 
thereof) then you need to load short-lived classes into a separate 
classloader so that they can be reclaimed when the classloader is 
unreachable. No classes loaded by the system loaders will ever be unloaded.

David

> TL;DR
> 
> My information is over 10 years old, when almost all of the JVMs were 32-bit; we ran into a problem with a coding pattern that constructed anonymous classes more quickly than the garbage collection could handle, and the permanent generation ran out of space, bringing down the VM.  At the time, it was running as an Applet, in a browser started by one of our thousands of users, owned by the user's employer (our customer), on a machine tightly configured by our customer's IT department to run multiple applications, where we do not have any ability to inject JVM launch options to, for example, control the size of the permanent generation.
> 
> It seemed at the time that the garbage collectors didn't even look in the permanent generation very frequently, so there as an architectural mis-match with high-speed construction of anonymous classes.
> 
> My understanding is that 64-bit JVMs don't have the concept of a permanent generation.  Is there a replacement in current JVMs where anonymous classes might still overflow?
> 
> While the application was usually launched as an Applet, it also has a main() and can run as an application.  That's the way it will run, going forward, obviously.  Now that we can influence the JVM startup options, I want to know if I should be considering this.  The reason is that I want to use this pattern to fix another problem with GUI activity (Java AWT).  This fix will spike the construction of anonymous classes significantly.**  If there is any likelihood of crashing the JVM (as it would, historically), I want to understand what the risk is.
> 
> ** The new pattern would use:
> 
> SwingUtilities.invokeLater(new Runnable() {public void run() {doGUI();}});
> 
> Where doGUI() might be as trivial as painting a dot.  This thing could resemble a denial-of-service attack on the thread constructor and GUI event thread scheduler, if such a DoS concept existed.  As long as garbage collection works, I expect it all should work...?
> 
> Thanks!
> 
> Mark Ludwig
>