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

[Ludwig, Mark]

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.

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