So the basics are I have Glassfish 2.1 and Java 1.6.0_15 and it will work for a few days but it eats up all the memory it can, seemingly no matter how high the max memory is set to. It’s a 32-bit jvm with the max memory now at 4GB and it uses it all up quickly then thrashes with the garbage collector bringing throughput to a crawl. So after a few tries I got a 3GB heap dump and opened it with YourKit.
The usage on this server is a swing client doing a few RMI calls and some REST https calls, plus a php web site calling a lot of REST https services.
It shows:
Name Objects Shallow Size Retained Size
java.lang.Class 22,422 1,435,872 1,680,800,240
java.lang.ref.Finalizer 3,086,366 197,527,424 1,628,846,552
com.sun.net.sll.internal.ssl.SSLSessionImpl 3,082,887 443,935,728 1,430,892,816
byte[] 7,901,167 666,548,672 666,548,672
…and so on. Gee, where did the memory go? Oh, 3 million SSLSessionImpl instances, that’s all.
It seems like all the https calls are causing these SSLSessionImpl objects to accumulate, but then they are never GC’ed. Looking at them in YourKit, the finalizer is the GC root. Poking around the web this looks very much like http://forums.sun.com/thread.jspa?threadID=5266266 and https://bugs.java.com/bugdatabase/view_bug;jsessionid=80df6098575e8599df9ba5c9edc1?bug_id=6386530
Where do I go next? How do I get to the bottom of this?
This seems to be fixed now with an upgrade to the latest JVM. 1.6.0_18 fixes bug 4918870 which is related to this. Prior to upgrading the JVM, I had several heap dumps with 100,000-4,000,000 SSLSessionImpl, now there are usually less than 5000 instances.