Comment by millerm | Hacker News Reader

Comment by millerm | Hacker News Reader

Umm. I trying to figure out how that title comes from what I just read in that article. The article shows a couple graphs comparing the max heap size and the max PermGen size of ~1000 different installations of java application servers. So? How can you state that java doesn't need that much memory after all? After all what? I know we've run out of PermGen with the JVM set to anything less than 192mb. We've got a pretty large app that (unfortunately) depends on a load of third party libraries. Too many libraries for my taste but that isn't my call. So, we must have this set or the server won't even start.

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.

Apologies for the confusion. The aim was to demonstrate that against our expectations the typical heaps in JVM landscape are not set that high and ~25% of the apps are doing just fine with less than 256MB of memory allocated.

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 ...

So, basically your data could just be showing that 25% of your install base have very small codebases. One of my applications, as an example, has 52MB of jar files. That's compressed data. Now, I am not sure how that eventually equates to how much ram is used to load these files (and I know that not every class will be loaded), but unzipping these jars ends up with over 203 megs of data. I have to have a large PermGen.

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.

Have you profiled any Grails applications? It was a 1.x grails system. I no longer work on the codebase, but we were running into permgen space above 256MB, we believed because of the way that the dynamic classes were created/never-destroyed in Groovy.

I concur! Claiming that Java is not "as memory intensive as thought" means to me that they compared the memory usage profile of java applications with similar applications developed in other languages.

Replying to myself as I see the title has changed. That makes more sense. Now my comment seems out of context. I had no idea you could change the title of a submission, especially after people commented on it. That's actually scary.

Reply on news.ycombinator.com