as well. Application servers, for example, typically specify a maximum permgen size of 128
MB, 192 MB, or more.
Contrary to its name, data stored in permgen is not permanent (metaspace, then, is a much
better name). In particular, classes can be eligible for GC just like anything else. This is a
very common occurrence in an application server, which creates new classloaders every time
an application is deployed (or redeployed). The old classloaders are then unreferenced and
eligible for GC, as are any classes that they defined. In a long development cycle in an ap-
plication server, it is not unusual to see full GCs triggered during deployment: permgen or
metaspace has filled up with the new class information, but the old class metadata can be
Heap dumps (see Chapter 7 ) can be used to diagnose what classloaders exist, which in turn
can help determine if a classloader leak is filling up permgen (or metaspace). Otherwise,
jmap can be used with the argument -permstat (in Java 7) or -clstats (in Java 8) to print
out information about the classloaders. That particular command isn't the most stable,
though, and it cannot be recommended.
1. The permanent generation or metaspace holds class metadata (not class data it-
self). It behaves like a separate heap.
2. For typical applications that do not load classes after startup, the initial size of this
region can be based on its usage after all classes have been loaded. That will
slightly speed up startup.
3. Application servers doing development (or any environment where classes are
frequently redefined) will see an occasional full GC caused when permgen/
metaspace fills up and old class metadata is discarded.
All GC algorithms except the serial collector use multiple threads. The number of these
threads is controlled by the -XX:ParallelGCThreads= N flag. The value of this flag affects
the number of threads used for the following operations:
▪ Collection of the young generation when using -XX:+UseParallelGC