Study1.

1.System.gc()

System.gc()메서드는 아래와 같이 정의될 수 있다.

public static void gc()

Runs the garbage collector.

Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.

The call System.gc() is effectively equivalent to the call:

 Runtime.getRuntime().gc()

->System.gc는 의도적으로 사용하여 메모리의 사용률을 빠르게 확보하기 위해 garbage Collector를 호출한다.(정확히 호출이란 의미 보다는.. gc를 제안하는 정도임)

Explicit garbage collection

A third category where developers often mistakenly think they are helping the garbage collector is the use of System.gc(), which triggers a garbage collection (actually, it merely suggests that this might be a good time for a garbage collection). Unfortunately,System.gc() triggers a full collection, which includes tracing all live objects in the heap and sweeping and compacting the old generation. This can be a lot of work. In general, it is better to let the system decide when it needs to collect the heap, and whether or not to do a full collection. Most of the time, a minor collection will do the job. Worse, calls to System.gc() are often deeply buried where developers may be unaware of their presence, and where they might get triggered far more often than necessary. If you are concerned that your application might have hidden calls to System.gc() buried in libraries, you can invoke the JVM with the -XX:+DisableExplicitGCoption to prevent calls to System.gc() and triggering a garbage collection.

->System.gc()는 사실 적당한 시간에 gc를 하도록 제안한다. 불행히도 System.gc()는 gc대상이던 아니던 Old영역 메모리의 정리작업을 야기시킨다. 이것은 많은 부하를 낳는다.일반적으로 System.gc()는 시스템이 heap메모리를 정리할 시기를 결정하는 것을 더 잘한다. 더 나쁜것은, System.gc()는 종종 개발자들이 무의식적으로 코딩한 소스에 존재함으로써 묻여지는 경우가 있고 필요보다 더 많이 사용되어진다. 만일 코딩한 소스중에 System.gc()메서드가 묻혀져있다면, jvm에게 강제 gc를 유발시키는 System.gc()옵션을 막는 -XX:+DisableExplicitGCoption 옵션을 JVM에 추가하도록 권한을 줄 수 있다.

2.HP log의 포맷과 정의

>>임의로 OOM발생시킨 후 hp gc log를 출력해봄

<GC: 1 12  5604.842262 45 1088 15 1288568832 1088 1288568832 58422112 59188080 161021952 962355496 964035496 3221225472 1075727920 1075727920 1610612736 0.076963 0.076963 >

Comprehensive HP GC Logs

  At every garbage collection, the following 20 fields are printed:
   <GC: %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16 %17 %18 %19 _ >
   
     %1:  Indicates the type of the garbage collection.
           1: represents a Scavenge (GC of New Generation only)
              %2: indicates if this is a parallel scavenge.
                   0: non-parallel scavenge
                   n(>0): parallel scavenge, n represents the number of 
parallel GC threads
   
           2: represents an Old Generation GC or a Full GC
              %2: indicates the GC reason:
                   1: Allocation failure, followed by a failed scavenge, 
leading to a Full GC
                   2: Call to System.gc
                   3: Tenured Generation full
                   4: Permanent Generation full
                   5: Scavenge followed by a Train collection
                   6: CMS Generation full
                   7: Old generation expanded on last scavenge
                   8: Old generation too full to scavenge
                   9: FullGCAlot
                  10: Allocation profiler triggered
   
           3: represents a complete background CMS GC
              %2:  indicates the GC reason:
                   1: Occupancy > initiatingOccupancy
                   2: Expanded recently
                   3: Incremental collection will fail
                   4: Linear allocation will fail
                   5: Anticipated promotion
   
           4: represents an incomplete background CMS GC
                 (exited after yielding to foreground GC)
              %2:  n.m
                   n indicates the GC reason:
                     1: Occupancy > initiatingOccupancy
                     2: Expanded recently
                     3: Incremental collection will fail
                     4: Linear allocation will fail
                     5: Anticipated promotion
                     6: Incremental CMS
                   m indicates the background CMS state when yielding:
                     0: Resetting
                     1: Idling
                     2: InitialMarking
                     3: Marking
                     4: FinalMarking
                     5: Precleaning
                     6: Sweeping
   
     %3:  Program time at the beginning of the collection, in seconds
   
     %4:  Garbage collection invocation. Counts of background CMS GCs
           and other GCs are maintained separately
   
     %5:  Size of the object allocation request that forced the GC,
           in bytes
   
     %6:  Tenuring threshold - determines how long the new born object
           remains in the New Generation
   
     The report includes the size of each space:
        Occupied before garbage collection (Before)
        Occupied after garbage collection (After)
        Current capacity (Capacity)
     All values are in bytes
   
     Eden Sub-space (within the New Generation)
       %7:  Before
       %8:  After
       %9:  Capacity
   
     Survivor Sub-space (within the New Generation)
       %10:  Before
       %11:  After
       %12:  Capacity
   
     Old Generation
       %13:  Before
       %14:  After
       %15:  Capacity
   
     Permanent Generation (Storage of Reflective Objects)
       %16:  Before
       %17:  After
       %18:  Capacity
   
       %19:  The total stop-the-world duration, in seconds.
   
       _:  The total time used in collection, in seconds.

   

참고:IBM

http://pic.dhe.ibm.com/infocenter/sfsf/v9r1/index.jsp?topic=%2Fcom.ibm.help.perf.manage.doc%2Fc_FND_PM_ComprehensiveHPGCLogs.html