23

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.

Eleco
  • 3,194
  • 9
  • 31
  • 40

1 Answers1

18

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.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • thanks - I see what you mean... but why are these messages specifically directed onto the output console, instead of, say, the gc logs ? Do they have some kind of special significance (impact on performance maybe)? – Eleco May 14 '10 at 12:30
  • As far as I know it is by default not logged. It will only be logged when you use `-verbosegc` argument. How are you executing the JVM? What arguments did you (or the IDE) use? This should not have a performance impact. The GC usually only runs when there is room for (i.e. the JVM has nothing else to do) or at the last moment when the max mem is reached. Those logs are only useful for informal/debugging purposes. – BalusC May 14 '10 at 12:35
  • I've edited the original question to include the JVM switches used... I would have thought that any gc-related message would go to the gc.log log file, but then again maybe clearing softreferences is a special case. – Eleco May 14 '10 at 12:45
  • 1
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6637203 tells me it is fixed for my version, but it is not... i have still those messages in gc.log just like the original question says. java -version java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode) – Janning Vygen Mar 22 '11 at 20:26