Skip to Content
Although there are quite a lot of applications which ‘translate’ the GC output to some readable format, it may be useful *to understand directly the output provided by the –verbose:gc* parameter, both for IBM and Sun JDKs. I’d like to start with some examples of garbage collections created by the IBM 1.4.2 JDK. I assume that you already know *how the garbage collector works*, but anyway I will explain briefly its behavior: The memory management consists of 2 processes: Garbage Collector and Allocator. The java objects are allocated to the different areas of storage in the heap, and there they are alive while there is a pointer to them (object is reachable). If the object is no longer needed, it becomes garbage. Then the Garbage Collector should ensure that the JVM resources are released. If the JVM cannot allocate a java object because there is no contiguous space, then an *allocation failure *takes place and the Garbage Collector is invoked. The Garbage Collector mission is to collect all the garbage from the heap. The GC process can be started due to an allocation failure or directly by being called by system.gc()



This is a real GC output where I’ve just separated the different tags with colors so that the example is clearer:


*1.* *NOTE:* If the garbage collector is triggered by the system.gc(), then the tag would be something like: *2.* This indicates the number of bytes requested by the allocation, in that case 48. *3.* This is the status of the nursery generation when the failure occurs. In that case there were no freebytes from a total of 268435456 (256M). So the percentage of free memory is 0%. *4.* For the tenured generation, we have 532690160 free bytes from 536870912 (512M), so the percentage of free memory is 99%. We can see the status of the different heap areas, the SOA (small object area) and the LOA (large object area). *5.* As a result, a garbage collector *6.* The ‘flipped’ tag indicates that 148478 objects were flipped in the survivor space during the garbage collection. *7.* The total time taken to carry out the scavenger collection was 64,127ms. *THE GLOBAL COLLECTION*  

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Tom Cenens
    Hello Desiree

    Your blog is welcome to help others understand how garbage collection works.

    Understanding how garbage collections works is important for both technical people (administrators etc) and developers.

    I still see that there is a lot of confusion on how it all works and a lack of knowledge on garbage collection as a technical topic.

    Kind regards


    1. Desiree Matas Post author
      Hello Tom,
      Thank you for your comment. I totally agree with you and I hope this blog is useful to understand a bit more how the JVM works.
      Best regards,
  2. David Hull
    Thanks Désirée for posting this blog, there is a lot of good explanations here that will be helpful to Java administrators!



Leave a Reply