And another aspect we wished to demonstrate was the sheer size of permanent generation on some of the applications. I have yet to face a leak-free app where permgen > 256MB seems justified ...
Perhaps the tool you install should be showing the number of classes loaded and the size of the code in general. But, again what's in a jar file can't tell you how many classes will be loaded because many common API such as hibernate and spring generate thousands and thousands of dynamic proxies that end up being stored in memory for the lifetime of that application.
The data also doesn't show if the higher heap users tested out running a lower PermGen/Heap and ran out of memory, hence their increased size. I'd rather allocate too much memory though than run out of memory at a peak time and have one of my hospitals deal with downtime because I saved $25 worth of RAM.
Anyway, I'll read the followup but I hope it has more info. The key is you have to profile your application, tune it and your done.
All applications are different and have different memory requirements. Too low of a setting and you are constantly thrashing or running out of memory. Too large and you have huge garbage collection times. It has to be tuned. Now, I've heard (as I haven't really looked into it yet) that the JVM in the JDK 8 distribution has gotten rid of PermGen setting. So, I'm curious to know what 'they' are doing now. Is the G1 garbage collector the new default in JDK 8? Does that not have the PermGen or is this something different?
Anyway, I don't know what this post is about yet. They probably should have just finished the thing instead of saying: "If you managed to get this far, then you are most likely interested to hear about our forthcoming posts. Stay tuned by subscribing to our Twitter feed." It was worthless.