SUN JDK 1.4.2 GC 정책

gc collection : http://java.sun.com/docs/hotspot/gc1.4.2/index.html
   
    1. Default collection
   
    2. Throughput Collector : -XX:+UseParallelGC
        young generation collector의 병렬사용.
        tenured generation collector는 default collector 사용.
        throughput 향상.
        default collector와 유사하나 멀티 스레드로 minor collection 수행.
        major collection은 default collector와 동일.
        N CPU만큼 N개의 gc thread 사용.
        gc thread 개수는 지정가능(-XX:ParallelGCThreads=<desired number>)
        1 CPU인 경우 병렬처리에 의한 추가적인 오버헤드로 default gc처럼 동작하지 않는다.
        2 CPU인 경우 default gc처럼 동작하며 2 CPU 이상인 경우 minor gc pause times의 감소 가능.
        -XX:+UseAdaptiveSizePolicy(1.4.1 이후 default option) - gc 타임, 메모리 할당 비율, gc후 여유 공간에 대한 통계로 최적의 young/tenured 영역의 크리를 조절한다. -verbose:gc 옵션으로 확인.
           
        AggressiveHeap - Server Performance Option : -XX:+AggresiveHeap
            이 옵션은 machin의 메모리 사이즈와 프로세서 수를 관찰하고 최적을 위한 다양한 파라메터들을 세팅하려 시도한다.
            4CPU 에서 유용. 메모리는 최소 256MB이상.
            높은 성능과 확장성, 쉬운 성능 튜닝
       
   
    3. Concurrent Log Pause Collector :
        -XX:+UseConcMarkSweepGC
        -XX:-UseParallelGC (multi processor인경우 자동으로 true)
        -XX:+CMSParallelRemarkEnabled (remark 시 일시 중단을 멈추는 옵션. 1.4.2 버그로 판명되어 (-) 로 사용해야 함. default가 (+) 이므로 -XX:-CMSParallelRemarkEnabled 명시적으로 사용함.)
        tenured generation collector에서 사용.
        변개의 collector thread 사용으로 동시실행하며 collection동안 짧은 주기의 정지가 일어나며 전반적인 throughput이 저하됨.
        shorter garbage collector pauses로 부터 이점을 얻을수 있고 공유 processor resources의 여유가 있는 경우 사용.
        2개 이상의 processor에서 이점이 생길수 있지만 low pause time을 고려.
        Concurrent collector에서 사용되는 테크닉 - http://research.sun.com/techrep/2000/abstract-88.html
       
        Young Generation Guarantee
            eden과 survivor space의 모든 object를 위해 tenured 영역에 연속된 충분한 공간 필요(fragment 방지).
            (eden과 survivor space에 할당된 사이즈를 알릴 방법이 없으므로..)
            충분한 heap size 필요. tenred 영역이 young 영역과 동등하게 증가함. 정확한 값은 application에 의존적임.
       
        Full Collections
            Concurrent collector는 single gc thread 사용하며 application thread와 함께 동작한다.
            그러므로 짧은 지연이 발생한다. tenured 영역이 차기전에 작업을 마치지 못한다면 모든 application thread는 정지되고 gc를 완료한다.
            해당 현상은 full gc라 말하며 concurrent collection parameter의 조정이 필요할 수 있다.
       
        Floating Garbage
            gc에 의해 살아있는것으로 발견된 object들이 gc가 끝날때 수명을 다할수 있는데 이런 object를 floating garbage라 한다.
            floating garbage의 양은 concurrent collection의 길이와 application 특성에 의존적이다.
            rough한 규칙은 floating garbage 양희 20%정도가 tenured 영역의 사이즈를 증가시킨다.
            floating garbage는 다음 gc때 collected 된다.
           
        Pauses
            concurrent collector는 concurrent collection cycle 동안 두번 정지한다.
            first pause : 살아있는 객체를 mark할때 [root로 직접 접근가능한 object(thread stack의 objects, static objects..)와 heap에서의 다른곳(young 영역)의 objects]
                                        이를 initial mark라 한다.
            second pause : marking이 끝나고 application thread의 동시실행에 의한 concurrent marking 구간동안 빠트린 object를 찾을때
                                        이를 remark라 한다.
           
        Concurrent Phases
            concurrent marking은 initial mark와 remark 사이에 일어난다.
            concurrent marking동안 concurrent gc thread는 processor resources를 사용한다.
            remark 후에 dead object로 수집된 것에 대한 concurent sweeping 구간을 수행한다.
            이 구간동안 concurrent gc thread는 다시 application으로부터 processor resource를 가져간다.
            sweeping 구간후에 concurrent collector는 다음 full gc가 일어날때까지 sleep한다.

        Measurement with the Concurrent Collector
            CMS-initial-mark : concurrent collection cycle의 시작
            CMS-concurrent-mark : cncurrent marking 구간의 끝
            CMS-concurrent-preclean :
            CMS-remark : remark 준비
            CMS-concurrent-sweep : concurrent sweeping 구간의 끝
            CMS-concurrent-reset : 마지막을 의미
            EX :)
                [GC [1 CMS-initial-mark: 13991K(20288K)] 14103K(22400K), 0.0023781 secs]
                [GC [DefNew: 2112K->64K(2112K), 0.0837052 secs] 16103K->15476K(22400K), 0.0838519 secs]
                ...
                [GC [DefNew: 2077K->63K(2112K), 0.0126205 secs] 17552K->15855K(22400K), 0.0127482 secs]
                [CMS-concurrent-mark: 0.267/0.374 secs]
                [GC [DefNew: 2111K->64K(2112K), 0.0190851 secs] 17903K->16154K(22400K), 0.0191903 secs]
                [CMS-concurrent-preclean: 0.044/0.064 secs]
                [GC[1 CMS-remark: 16090K(20288K)] 17242K(22400K), 0.0210460 secs]
                [GC [DefNew: 2112K->63K(2112K), 0.0716116 secs] 18177K->17382K(22400K), 0.0718204 secs]
                [GC [DefNew: 2111K->63K(2112K), 0.0830392 secs] 19363K->18757K(22400K), 0.0832943 secs]
                ...
                [GC [DefNew: 2111K->0K(2112K), 0.0035190 secs] 17527K->15479K(22400K), 0.0036052 secs]
                [CMS-concurrent-sweep: 0.291/0.662 secs]
                [GC [DefNew: 2048K->0K(2112K), 0.0013347 secs] 17527K->15479K(27912K), 0.0014231 secs]
                [CMS-concurrent-reset: 0.016/0.016 secs]
                [GC [DefNew: 2048K->1K(2112K), 0.0013936 secs] 17527K->15479K(27912K), 0.0014814 secs]
       
        Parallel Minor Collection Options with the Concurrent Collector
            Multiple Processor platform에서 UseParNewGC option은 기본으로 true이다.
            만일 UseParNewGC 옵션을 사용한다면 remark 정지를 제거하기위해 CMSParallelRemarkEnabled option을 사용한다.
            -XX:+CMSParallelRemarkEnabled
           
   
    4. The incremental low pause collector (sometimes called train)
        -XX:+UseParallelGC or -XX:+UseParNewGC과 같이 사용하면 안된다.
        incremental collector의 목적은 긴 full gc를 피하기 위해 minor gc때에 full gc의 일부를 수행한다.
        incremental collector는 non-incremental full gc를 찾을경우가 있는데 이는 OOM을 피하기 위해서이다.
        incremental collector는 fragmentation을 유발할수 있기 때문에 큰 tenured 영역이 요구될 수도 있다.
        throughput은 default collector 보다 느리다.
       
        Measurements with the Incremental Collector
            Train : incremental collection 완료.
            Train MSC : full gc를 의미 (mark-sweep-compact)
            EX :)
                [GC [DefNew: 2074K->25K(2112K), 0.0050065 secs][Train: 1676K->1633K(63424K), 0.0082112 secs] 3750K->1659K(65536K), 0.0138017 secs]
                [GC [DefNew: 2049K->2049K(2112K), 0.0003304 secs][Train MSC: 61809K->357K(63424K), 0.3956982 secs] 63859K->394K(65536K), 0.3987650 secs]
        일부분은 tenured generation 이 일어나며 major gc 의 일시멈춤현상을 최소화 할 수 있다.
        그러나 throughput 을 고려할 때 default collector 보다 느리다.
        -Xincgc 옵션을 사용하면 되나 다른 옵션과 함께 사용하면 JVM이 어떻게 동작할지 예상할 수 없으므로
        같이 사용하면 안된다.

    5. Other Considerations
        보통 permanent 영역은 gc와 관련이 없지만 JSP같은 경우 많은 양의 class를 로딩하기 때문에 MaxPermSize 조정이 필요할수 있다.

        -Dsun.rmi.dgc.client.gcInterval=3600000 (1시간마다 full gc)
        -Dsun.rmi.dgc.server.gcInterval=3600000 (최대 지정 가능 값 : Long.MAX_VALUE)
       
        Soft reference는 client보다 server VM에서 더 느리게 clear된다. 다음옵션으로 조정가능
        -XX:SoftRefLRUPolicyMSPerMB=10000 (default 1000 ms per Megabyte)