Message6147

I like jvisualvm, definitely a good tool. Based on the recommendation by Charlie Nutter from his blog, I'm now trying the Eclipse Memory Analyzer Tool (mat), which is available as a separate download. (I would like to do that, since I currently use IntelliJ, and I very much like it as my IDE.)

So here's what I have found using the leak suspects report:

Run with a 1000 connections or so, get this

One instance of "com.google.common.collect.CustomConcurrentHashMap" loaded by "sun.misc.Launcher$AppClassLoader @ 0x1089ef270" occupies 2,574,736 (25.03%) bytes. The memory is accumulated in one instance of "com.google.common.collect.CustomConcurrentHashMap$Segment[]" loaded by "sun.misc.Launcher$AppClassLoader @ 0x1089ef270".

For ~10000 connections, this is:

One instance of "com.google.common.collect.CustomConcurrentHashMap" loaded by "sun.misc.Launcher$AppClassLoader @ 0x1092d27e0" occupies 36,690,640 (82.85%) bytes. The memory is accumulated in one instance of "com.google.common.collect.CustomConcurrentHashMap$Segment[]" loaded by "sun.misc.Launcher$AppClassLoader @ 0x1092d27e0".

This the canonical map PyType#class_to_type. Now there's nothing wrong with it holding classes, but it should not be increasing in size. Watching jvisualvm, class loading stabilizes to approx 4000 classes for the duration of the run. So I think the most logical conclusion for now is that a class (presumably one of the socket classes) is somehow getting attached with this 4K chunk/connection that Alan observed.

As usual, more analysis needed, but I think we may have something we might have something we can work on now.