Is the permanent generation always collected serially on the HotSpot VM?

Question

From reading a rather mature Oracle blog entry, I learned that

(...) the permanent generation is currently collected serially.

However, this blog entry is from quite some years ago and I was wondering how the recent advancements in garbage collection algorithms might have changed the accuracy of this statement. I am especially wondering about the new G1 garbage collector which is desribed by Oracle with:

The older garbage collectors (serial, parallel, CMS) all structure the heap into three sections: young generation, old generation, and permanent generation of a fixed memory size. (...) When performing garbage collections, G1 operates in a manner similar to the CMS collector.

but never mentions the permanent generation in the entire tutorial again.

From reading about CMS - which according to the above statement works similar to G1 - I did not find any explicit information on the permanent generation either but learned from this other blog entry that

(...) the Concurrent Mark and Sweep does not compact at all. Once objects cannot be allocated anymore a serial major GC is triggered.

So I am wondering if modern garbage collectors, such as CMS or G1, just completely ignore the permanent generation and leave it to full GC invocations which run the old serial GC to clean out the permanent generation (while this serial GC also collects the young and mature generations serially which I would not understand to be desirable when G1 was used instead of CMS). I am mainly interested in finding out if it is more expensive in terms of STW and collection time to perform garbage collection on the permanent generation than it is to collection the tenured generation.

Bonus question: The Oracle tutorial mentions that the permanent generation is part of the heap. I always thought that the permanant generation was explicitly allocated outside of the heap. Did this change in recent HotSpot implementations?

Thank you for your help!

Christmann

The most recent change is that there is no more permgen in Java 8 – Darrick

That is of course correct. However, renaming something into meta space and not limiting the size of this space does not make the conceptual problem go away. This new meta space will still need to be garbage collected and I guess Oracle will use the same algorithm on it as it currently uses on the perm gen. – Christmann

That's true but it may get rid of the problem that you had to size regular heap + permgen independently and could run out of resources on one of them while the other had still some space. The problem that you may need more than you have is probably not solvable at all. – Darrick

Answer 1

There is a JEP156 about making G1 able to unload classes without a full GC, but the dependences section states that it makes sense to wait with [JEP122] until the permanent generation is gone to make JEP156 easier to implement.

So it looks like that this problem may indeed be solved in Java 8, but not just thanks to the meta space, instead because meta space is taken as a pre-requisite to do incremental GC of classes.

That's my understanding.

edit: Over the past few days I've been listening to some of this year's JavaOne sessions and quite luckily I found one just today about PermGen removal that says it all:

• HotSpot currently requires full GC to collect PermGen
• This will still be true even after introduction of Metaspace
• The summary slide at the end seems to confirm that JEP156 is still planned (but she does not talk about it)
• It even answers the bonus question for which I had an answer but no source: Yes, PermGen is in the heap

Mullion

Thanks for the interesting links. I just don't get how the meta space makes this problem go away. Why would the meta space not need to be garbage collected anymore? And what happens today? – Christmann

Hmm maybe I wasn't clear, but this is not what I said. What I meant is that Oracle decided to wait before metaspace before implementing JEP156. So it means that it is still serial today, and will still be in Java 8, until they implement JEP156. – Mullion