Menu
Anyone can explain why the lines below appear in the output console at runtime ?
(one possible answer would be full permGen, but this can be ruled out since the program only uses 24MB out of the max100MB available in PermGen)
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor28]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor14]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor4]
[Unloading class sun.reflect.GeneratedMethodAccessor5]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor38]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor36]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor22]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor8]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor39]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor16]
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor2]
[Unloading class sun.reflect.GeneratedConstructorAccessor1]
The program runs with the following params:
-Xmx160M
-XX:MaxPermSize=96M
-XX:PermSize=96M
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+PrintGCTaskTimeStamps
-XX:+PrintHeapAtGC
-XX:+PrintTenuringDistribution
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintGCTimeStamps
-verbose:gc
-Xloggc:/logs/gc.log
There's plenty of space in the heap and in permGen.
435
Class unloading is a desirable optimization feature for any Java Virtual Machine implementation. Similar to normal garbage collection, class unloading is the process of freeing memory occupied by various loaded classes that are no longer referenced by the current program execution context.
Class loading loads, verifies, prepares and resolves, and initializes a class from a Java class file. Loading involves obtaining the byte array representing the Java class file.
Class loading is done by ClassLoaders in Java which can be implemented to eagerly load a class as soon as another class references it or lazy load the class until a need of class initialization occurs. If Class is loaded before its actually being used it can sit inside before being initialized.
Those classes are hold as softreferences which are always eligible for GC. The GC does not per se only run when the max memory is reached, it will also run when there is room for it, if you understand what I mean.
Those classes are by the way used "under the hoods" of the Serialization API which uses reflection to access fields and invoke methods.
Update: as to logging the class unloading to stdout instead of the path as specified in -Xloggc, there has been a bugreport for exactly this problem: Bug ID 6637203. This was fixed 4 months back. Upgrade your JVM to the latest.
87
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
