JDK 8 에서는 Heap 영역 중 Perm 영역이 사라졌다. 

정확하게는 사라졌다기 보다 두개로 쪼개졌고, Full GC 의 대상에서 제외되었다. 


JDK8에서는 jstat 수행결과가 다음과 같이 나오는데...

$ jstat -gcutil 66793 1s

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   

  0.00   1.34  76.18  30.51  97.54  96.72     45    0.138     0    0.000    0.138


대체 Perm 영역을 나타내는 P가 없어지고 M과 CCS가 나타났는데 이게 뭘까? 


궁금하다면 아래 링크 클릭 ! 


http://java-latte.blogspot.kr/2014/03/metaspace-in-java-8.html

(내 머리속에 들어갔다 온 것처럼 내가 원하는 모든 것을 깔끔하게 정리 !)

신고
Posted by tuning-java Trackback 0 : Comment 0

오라클에서 이런 사이트를 제공하는구나. Garbage First 에 대해서 알고 싶다면 클릭 !!!

http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/G1GettingStarted/index.html#overview

관련하여 찾아 보니

http://www.oracle.com/technetwork/tutorials/index.html

OBE라고 오라클에서 Oracle By Example이라는 사이트를 제공하는군.

오라클로 넘어가고 나서 가장 훌륭한 작업!!!. ㅎㅎㅎ


추가로 볼만한 것들

GC: http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html

Command line tools : http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/JavaJCMD/index.html

신고
Posted by tuning-java Trackback 0 : Comment 0
앞서 String.intern() 메소드를 사용하면 Perm 영역에서 GC가 많이 발생할 수 있다고 했다. 
http://tuning-java.com/455 참고.
그런데, 이 글을 읽는 분들은 대부분 아시겠지만, Perm 영역에는 클래스와 메소드등의 정보가 들어가게 된다. 많은 클래스를 읽어들일 수록 Perm 영역은 당연히 부족해지고, Full GC를 발생시킬 수 있다. 

이런 문제를 발생시키는 주된 원인은 Reflection을 사용해서 메소드 호출등을 할 경우도 포함된다.

왜 Perm 영역에서 Full GC가 발생할 수 있는지에 대한 설명이 잘 되어 있는 문서다. 
http://anshuiitk.blogspot.com/2010/11/excessive-full-garbage-collection.html

 관심 있는 분들은 한번 정도 읽어 보면 좋을 듯 하다. 

그리고, 
http://coding.derkeiler.com/Archive/Java/comp.lang.java.programmer/2006-11/msg00122.html
이 글도 보면 도움이 될 것이다. 
 
신고
Posted by tuning-java Trackback 0 : Comment 0
내가 지금까지 본 글 중에서 가장 마음에 쏙 들게 작성되어 있다.
(물론 시간 관계상 그림만 봤다. ㅎㅎ)

http://www.ibm.com/developerworks/java/library/j-codetoheap/index.html 
신고
Posted by tuning-java Trackback 0 : Comment 0
내가 기고한 어떤 글에 어느 분께서 질문을 올려서 여기에 정리한다.
질문의 골자는 "다른분께서 Perm 영역에서는 GC 가 발생 안한다고 했는데, Perm영역에서도 GC발생한다는 것이 이상하다"는 내용이다. 
나도 내 눈으로 확인하기 전까지는  GC가 발생안한다고 생각했으므로 당연한 질문이라고 생각한다.
지금까지 내가 무슨 이야기하는지 이해가 안되시는 분은
이글 (http://helloworld.naver.com/helloworld/1329) 먼저 읽으시면 조금 이해가 쉬울 것이다. 

다음의 소스를 보자.

public class InternTest {

  public static void main(String[] args) throws Exception{

    InternTest test=new InternTest();

    Thread.sleep(10000);   System.out.println("Starting");

    while(true) {

      test.callIntern();Thread.sleep(5000);

      System.out.print(".");

    }

  }

  private void callIntern() {

    for(int loop=0;loop<10000;loop++) {

      String a="1234567890"+System.nanoTime();

      String newString=a.intern();

    }

  }

}

 아주 간단한 소스인데, callIntern() 이라는 메소드를 보면 새로운 String을 계속 만들어 intern() 메소드를 호출하고 있다. 
이 클래스를 컴파일하고 jstat으로 모니터링하면 다음과 같은 결과를 볼 수 있다.
(jstat에 대해서는 "자바 성능을 결정짓는 코딩 습관과 튜닝 이야기"를 참조하거나,
http://helloworld.naver.com/helloworld/6043 를 참고하기 바란다.)

예를 들어 이 프로그램의 프로세스 ID가 4800 일 때 결과는 다음과 같이 출력된다.  

$ ./jstat -gcutil  4800 3s
  S0   S1   E     O    P     YGC  YGCT  FGC FGCT  GCT
  0.00 0.16 10.43 8.79 
98.37 3869 1.247 87  1.815 3.061
  0.02 0.00 52.12 8.77 
45.21 3884 1.250 88  1.840 3.090
  0.00 0.16 83.39 8.77 
98.89 3903 1.257 88  1.840 3.097
  0.00 0.16 27.11 8.78 
15.04 3919 1.262 89  1.857 3.119

 
P라고 표시되어 있는 내용의 값이 계속 변경되는 것을 볼 수 있다.
여기서 P가  Perm 영역의 사용량(%)인데, 보는 것과 같이 그 크기가 지속적으로 바뀌는 것을 볼 수 있다.
그리고 우측에 있는 FGC라는 값도 증가하는 것이 보인다.

자바의 Perm 영역에 클래스와 메소드 정보만 저장되어 있다고 생각하는 것이 일반적이지만,
실제로는 intern된 String 값도 이 영역에 저장된다. 

참고) intern된 String은 뭘까?
String은 기본적으로 equals()메소드로 값을 비교한다. 그렇게 되면 char값들을 비교하기 때문에 성능이 느릴 수 있지만, String 의 실제 값에 대해서 intern() 메소드를 호출하면 해당 값은 equals() 메소드가 아닌 == 으로 비교가 가능하다. 추가로 이  intern()메소드는 native 메소드로 선언되어 있다. 
하지만, 이렇게 String비교를 조금 빠르게 하기 위해서 intern() 메소드를 호출한 후 결과를 비교하는 것은 Perm영역을 마구잡이로 사용하겠다는 의미이기 때문에 "절대" 권장하는 방법은 아니다. 그냥 이런 것이 있구나 정도로 참고하고 있기 바란다. ^^;

추가로,
Perm영역에 어떤 데이터들이 저장되어 있는지 보려면 
jmap -permstat pid
명령어로 확인하면 되며,
그 결과에 가장 첫 출력물을 보면 interned String 크기가 출력된다.


2013.8.5 추가
와 
(의 댓글)에 따르면 JDK 7 이상 부터는 String.intern() 메소드의 호출 결과가 더 이상 Perm 영역에 들어가지 않고 Heap 영역으로 들어가게 되었네요. ^^;


 


신고
Posted by tuning-java Trackback 0 : Comment 3
http://www.infoq.com/presentations/Diagnosing-Memory-Leaks

링크에 있는 자료를 보면 자바 메모리릭에 대한 좋은 정보를 얻을 수 있다.

화면의 상단에 있는 동영상을 수행하면, 중앙에 있는 슬라이드가 바뀌면서 보인다.

여기서 보여주는 자료를 다운로드할 수만 있다면 좋으련만...
신고
Posted by tuning-java Trackback 0 : Comment 0
지난주에 회사에서 "GC 튜닝의 이해"라는 과정을 개설해서,
강의를 했다. 

강의 자료를 만들고 있는데,
도대체 자바의 Permanent 영역에는 정확히 어떤 놈들이 있는 것일까?
라는 의문이 생겨서 여기저기 찾아 보다가, 가장 정리가 잘 되어 있는 놈을 발견했다.

궁금하신 분들은 아래 글을 읽어보기 바란다.
http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_generation

신고
Posted by tuning-java Trackback 0 : Comment 0
자바의 GC 방식에는 여러가지가 있지만,
최근에 나온 기술에는 G1이라는 것이 있다.
최근에 나온 JDK 6.0 update 14에는 early access 로 G1을 사용할 수 있도록 했다.
G1을 적용하기 위해서는 java start option에
-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC
라고 명시해 주면 된다.

추가로 G1을 사용할 때 GC로 인한 최대 대기시간을 지정하기 위한
-XX:MaxGCPauseMillis=<X>
옵션을 추가할 수 있으며,
-XX:GCPauseIntervalMillis=<X>
옵션을 통해서 GC 대기 사이의 간격을 지정할 수 있다.
그런데 여기서 중요한 것은
이 옵션은 Goal 이다. Promise나 guarantee 가 아니라는 것이다.
(목표일 뿐이고, 이건 약속이나 보장한다는 것이 아닐 뿐이고~~)

G1이 다른 GC와 다른 것은 GC를 담당하는 New와 Old의 장벽이 사라졌다는 것~~~
자세한건 아래 링크의 비됴나 문서를 함 보시길~~~

Sun Tech Days 2008-2009 자료 보기
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5419&yr=2008&track=javase


신고
Posted by tuning-java Trackback 0 : Comment 0
GC가 뭔지 잘 모르시는 분들은 제 블로그의 다른 글을 찾아보시거나,
"자바 성능을 결정 짓는 코딩 습관과 튜닝 이야기"를 참조하시길...

자바의 메모리 구조는 다음과 같이 되어 있다.
  • Code Cache: contains memory used for compilation and storage of native code
  • Eden Space: pool from which memory is initially allocated for most objects
  • Survivor Space: pool containing objects that have survived Eden space garbage collection
  • Tenured Gen: pool containing long-lived objects
  • Perm Gen: contains reflective data of the JVM itself, including class and memory objects
  • Perm Gen [shared-ro]: read-only reflective data
  • Perm Gen [shared-rw]: read-write reflective data

    아래는 GC를 어떻게 튜닝하는지에 대한 자세한 설명이 있는 사이트 링크다.
    http://java-monitor.com/forum/showthread.php?t=30

    이것도 귀찮은 분을 위해서 더 간단한 튜닝 정보
    http://developer.amd.com/documentation/articles/pages/4EasyWaystodoJavaGarbageCollectionTuning.aspx

    완벽한 GC의 방식과 처리에 대한 자세한 정보를 보려면 아래 링크에 있는 PDF 파일을 참조하는 것도 좋다.
    http://www.cecmg.de/doc/tagung_2007/agenda07/24-mai/2b3-peter-johnson/index.html


    한글로 된 설명을 보고자 하신다면
    다시한번 말씀드리지만,
    "자바 성능을 결정 짓는 코딩 습관과 튜닝 이야기"를 참조하시길...
    지금 생각해보면 이 책에 이 부분에 대한 설명을 좀 약하게 적었다는 생각이 많이 들긴 한다.
    다음책에선 자세히 적어놔야지...

    추가로 Java 6 GC 튜닝 방법에 대한 Sun의 자료는 아래와 같다.
    http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html

  • 신고
    Posted by tuning-java Trackback 0 : Comment 0

    http://java.sun.com/javaone/sf/2008/articles/rockstar_tonyprintezis.jsp

    먼저 위의 인터뷰 내용을 읽어보자.
    Garbage First Collector가 뭔지 대충 감을 잡을 것이다.

    분명 대부분 안읽어 보시겠지만....적어도 아래 줄들은 일어 주기 바란다.
    G1=next-generation low-pause garbage collector
    G1 will ultimately replace the Concurrent Mark-Sweep (CMS) garbage collector
    G1, even though it is generational, there is no physical separation between the two generations.

    Three Objectives of G1
    The first objective is consistent low pauses over time.
    The second objective is to avoid, as much as possible, having a full GC.
    The final objective is good throughput.


    if you care about getting the job done as quickly as possible, and don't care much for how long your application is going to be stopped by the garbage collector, the throughput collector is the best choice.

    if you have a batch job that is going to take a few minutes or a few hours and you want it to be done as quickly as possible, then a throughput collector is clearly the best choice.

    But, if you are working on a very interactive job that needs to interact with people, other applications, or users through web pages, then a low latency garbage collector is the best choice.


    Why does garbage collection take so long? ==> Garbage collection is very memory-bound. And memory speeds these days are quite slow compared to CPU speeds

    글 중간에는 다음의 내용을 읽어보라고 이야기한다.
    GC와 친해지는 코딩 방법
    http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-2906.pdf

    그리고, 저 이너뷰 한 사람이 사진을 잘 찍는가본데, 사진과 개발과의 상관관계를 아래와 같이 이야기 했다.
    You need to be committed and to be patient and try out things again and again, to make sure that you get it just right. I see some parallels between photography and development.

    마지막엔 그가 이야기하는 아름다운 코드란....
    Beautiful code is code that is simple, easy to understand, and efficient
    란다.

    더 자세한 내용을 보시려면 아래의 영어지만, 쉽지 않은 용어로 되어 있는 문서를 참조하기 바란다.
    http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf

    참고로 G1은 JDK 7 부터 추가된단다.
    그리고, early access 로 JDK 1.6.1에서 추가 되었다.
    http://www.tuning-java.com/272

    신고
    Posted by tuning-java Trackback 0 : Comment 1

    http://java.sun.com/performance/reference/whitepapers/tuning.html

    썬에서 제공하는 자바 튜닝 whitepaper

    물론 JVM 옵션 튜닝만 한다고 해서 답은 안나오겠지만,
    튜닝할게 더이상 없다면, JVM 버젼 upgrade 및 옵션 튜닝을 해야 할 것이다.

    아래는 이 글의 목차다.

    뭐 다 읽기 귀찮으신 분들은 4.2 부터 적용해 보시면 된다.

    1   Introduction

    1.1   Goals
    1.2   This is a Living Document
    1.3   How to Use this White Paper

    2   Best Practices

    2.1   Use the most recent Java™ release
    2.2   Get the latest Java™ update release
    2.3   Insure your operating system patches are up-to-date
    2.4   Eliminate variability

    3   Making Decisions from Data

    3.1   Beware of Microbenchmarks!
    3.2   Use Statistics
    3.3   Use a benchmark harness

    4   Tuning Ideas

    4.1   General Tuning Guidelines

    4.1.1   Be Aware of Ergonomics Settings
    4.1.2   Heap Sizing
    4.1.3   Garbage Collector Policy
    4.1.4   Other Tuning Parameters

    4.2   Tuning Examples

    4.2.1   Tuning Example 1: Tuning for Throughput
    4.2.2   Tuning Example 2: Try the parallel old generation collector
    4.2.3   Tuning Example 3: Try 256 MB pages
    4.2.4   Tuning Example 4: Try -XX:+AggressiveOpts
    4.2.5   Tuning Example 5: Try Biased Locking
    4.2.6   Tuning Example 6: Tuning for low pause times and high throughput
    4.2.7   Tuning Example 7: Try AggressiveOpts for low pause times and high throughput

    5   Monitoring and Profiling

    5.1   Monitoring
    5.2   Profiling

    6   Coding for Performance
    7   Pointers
    8   Feedback and the Java Performance Community

    8.1   Feedback
    8.2   Java Performance Community

    신고
    Posted by tuning-java Trackback 0 : Comment 0
    http://2005elc.elancer.co.kr/eTimes/page/eTimes_list.html?cstr=Q0FURUNPREU9QTEwMDAxNTAw

    자바 성능 튜닝은 JVM 옵션만 튜닝한다고 해서 되는 것은 아니다.

    하지만, Application 단에서 튜닝을 모두 마쳤을 경우 가장 마지막에 해야 하는 것이
    JVM의 GC 옵션 및 메모리 부분의 튜닝이다.

    물론 사람에 따라 방식이 틀려서 GC 옵션을 처음부터 할 수도 있다.
    신고
    Posted by tuning-java Trackback 0 : Comment 0
    http://ukja.tistory.com/category/Enterprise%20Java

    이 글을 작성하신 분께서는 JVM 떄문에 단단히 고생하신것 같다. ^^;

    제 책에 있는 메모리 부분에 대한 설명을 읽은 후 이 블로그에 있는 글을 읽으시면 굉장히 많은 도움이 되겠네요.

    특히 IBM JVM의 가장 큰 문제인 Compaction 문제에 대해서도 정리가 잘 되어 있다.
    신고
    Posted by tuning-java Trackback 0 : Comment 0