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

[Michael Rasmussen]

The concept of an anonymous inner class as it exists on the language level doesn't really exist in the JVM.

At compile time an anonymous inner class gets compiled into a .class file usually with a name like OuterClass$1, OuterClass$2 etc.

So there is only one Class for the anonymous class (including in permgen/metaspace), but as many instances as instantiated -- and the GCs today are very good at handling these very short-lived objects.


Even if using a lambda, the lambda meta factory will create just one class for the lambda, and instances of that class with be instantiated as needed (for a non-capturing lambda, it can even reuse the same instance).


/Michael

________________________________
From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> on behalf of Ludwig, Mark <ludwig.mark at siemens.com>
Sent: 27 November 2018 18:24:47
To: hotspot-dev at openjdk.java.net
Subject: Java AWT, Swing, threads, anon classes, and garbage collection

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