Paper_Design of Swap-aware Java Virtual Machine Garbage Collector Policy

Editor's Notes

• #2 안녕하세요. 서울대학교 분산시스템 연구실 석사과정 이효정입니다. 발표드릴 내용은 Design of Swap-aware JVM GC policy로, 리눅스 스왑시스템에 의한 오버헤드를 줄이기 위한 새로운 JVM GC 정책을 제안합니다. Our research is about designing a new JVM garbage collection policy , which should suppose to be decrease the overhead caused by LINUX system SWAP.
• #3 발표 순서는 다음과 같습니다. 기존 GC 정책이 리눅스 스왑 시스템에 의해 어떤 영향을 받는지 간단한 자바 프로그램으로 검증합니다. 그리고 발견된 문제를 해결하기 위한 두가지 방법을 제안합니다. 첫 번째 방법은 리눅스 LRU 리스트로부터 스왑아웃된 jvm 힙 오브젝트에 대한 힌트를 얻는 것입니다. 두 번째는 GC 타겟을 선택하는 단계에서 커널의 pagemap을 사용하여 해당 오브젝트의 페이지들이 스왑아웃되었는지 여부를 확인해서 GC 타겟으로부터 일차적으로 제외시키는 것입니다. 플래너 단계의 연구여서 새로운 방법 제안과 그를 위한 평가 계획까지를 본 발표에서 다룹니다. 이제 관련 내용에 대한 자세한 설명을 드리겠습니다. Here is the contents of our work. At first we made a simple java program to verify the impact that given by LINUX SWAP system during a JVM Full GC procedure. The impact was observed Then we proposed 2 solutions to solve the problem The first one is using a LRU list to manage the accessed objects in the JVM heap and screening out the one that might be swapped out within the help of the LRU list. The second solution is during the phase of selecting gc targets, linux pagemap information is used to verify each page that belongs to a object is swapped out or not. If it is, evict it from the gc targets
• #4 먼저, 검증에 사용된 간단한 자바 프로그램의 명세와 그 결과입니다. 시스템 환경 및 설정값을 설명드리면, JVM 힙 사이즈를 메모리사이즈 50G와 스왑영역 55G를 합한 105GB로 설정하였습니다. 또한, 한 번 할당되는 자바 오브젝트 사이즈는 1G로 정하였습니다. 검증 프로그램에는 먼저 60개의 오브젝트를 시퀀셜하게 할당하고, 메모리가 50GB이므로, 50번째 오브젝트가 할당될 때, 리눅스 스왑시스템의 영향이 시작됩니다. 60개 오브젝트를 모두 할당하고 나면 그 중 20개 오브젝트를 메모리에 남게하기위해 반복적으로 액세스합니다. 그 후 나머지 오브젝트 중 20개를 null로 재할당하여 GC의 타겟이 되도록합니다. 마지막으로 10개의 오브젝트를 더 할당합니다. 측정결과 70개 오브젝트가 모두 할당되면 full gc가 발생합니다. 결과에 의하면, 어떤 오브젝트를 GC 타겟으로 만들었는지, 또 어떤 오브젝트가 스왑아웃 되었는지에 따라 전체 GC에 걸리는 시간은 상이합니다. 최악의 경우 200초가 소요되며 이는 베이스라인 4번을 제외한 가장 빨리 끝나는 케이스인 20초보다 20배 느립니다. Here is our evaluation result of our validatation program. The system environment is as follows: the total JVM heap size is 105G, while the DRAM size is 50G and the swap space on the disk is 55G. The size of object is set to 1G. In the program, we first sequentially allocate 60 objects,. Since the dram is 50GB, when the 50th object is allocated , the linux system SWAP starts. After allocating 60 objects, we keep accessing 20 of them to keep them in the DRAM. and then assign null to 20 of them to create GC targets. At last we continue to allocate 10 objects From the result, we can see that, with different part of objects are set to null or swapped out, the total gc time and amount of swap is quite different. The longest time that gc takes is 204s which is almost 20 times than the shortest case.
• #5 이제 앞선 실험 결과에 대한 이유를 설명드리겠습니다. Openjdk8의 디폴트 Full GC 정책은 Parallel Compact Collector로, 힙 영역을 region 단위로 나누어 관리합니다. (디폴트 사이즈??? 512kB) 그림에서 보이듯, 인터널 세그먼테이션을 피하기 위해 region을 한 쪽으로 이동시키며, 이를 컴팩션이라고 합니다. 따라서, 만약 이런 컴팩션 대상이거나 GC 대상인 region들이 디스크로 스왑아웃되어있다면, GC동안 다시 메모리로 가져오는 오버헤드가 상당하게 됩니다. 결과적으로, 현재 GC 정책은 타겟을 결정하는데에 스왑 정보를 고려하지 않습니다. The reason why the result is different in the former experiment is as follows The default full GC policy of JVM in opensdk8 the policy named Parallel compactor collector. As the picture shows, to remove the internal segmentation, it will sliding the objects, which may even not be a GC target. So if the gc targets or the compaction targets are swapped out to the disk, during the procedure of gc, the overhead to bring them back to the dram would be huge. As a result , the current GC policy doesn't take the swap information into consideration when decide the targets
• #6 이런 이슈를 해결하기 위해 본 연구에서는 두 방법을 제안합니다. 첫번째로, 리눅스 스왑시스템이 스왑할 페이지를 LRU 리스트 기반으로 결정하기 때문에, LRU 리스트에서 어떤 region이 스왑아웃되었는지 여부에 대해 힌트를 얻을 수 있고 그 정보를 바탕으로 GC 혹은 Compaction 타겟으로부터 제외시킬 수 있을 것입니다. The first solution to optimize that problem is using a lru list to manage the accessed regions of each objects. Since linux swap system swap out pages based on lru list, we believed that using lru list to mange accessed regions could predict which region is swapped out or not and then remove them from the gc/compaction targets
• #7 다음은 제안한 두번째 방법입니다. 두 번째 방법을 설명하기 위해 먼저 Parallel GC의 세 가지 단계를 설명드리겠습니다. 첫 번째 단계는 마킹 단계로, 힙상의 live object에만 마킹하는 단계입니다. (bit set) 두 번째 단계는 서머리 단계로, region 별 live object의 비율을 계산하고, 어디까지 GC 타겟으로 할지를 정하는 단계입니다. 세 번째 단계는 앞서 언급했던 컴팩션 단계로 전 단계에서 결정한 GC 타겟에 따라 GC한 후 region들을 한 쪽으로 이동시키는 단계입니다. 여기서 제안한 방법은 두 번째 서머리 단계에서 리눅스 페이지맵의 정보를 읽어와 이 정보를 GC 타겟을 정하는 데에 반영하는 것입니다. 페이지맵에는 각 물리 페이지의 스왑여부에 대한 정보가 포함되어있습니다. 한 region에서 swap된 영역의 비율을 swapness라고 한다면 GC 타겟을 결정하는 단계에서 swapness라는 메트릭을 추가하여 GC할 영역을 정할 수 있을 것입니다. And before we talking about another solution I’d like explain the 3 phases of the procedure The first phase is called marking phase where jvm used to makring all the living objects there The second phase called summay phase where gc targets are selected The third phase call the compaction phase which used to move the objects according to the result of the above phases. Another solution is during the phase of calculating the. gc target, we read the information of linux pagemap. It contains the info of each phycal page’s swappness, which means It can tell us whether each page is in the memory or not. And then we will use this informantion to optimize the algorithm used to select gc targets.
• #8 앞서 제안한 방법은 검증 프로그램과 같이 메모리 사용량이 높고 로컬리티가 높은 실제 워크로드에서 그 효과가 좋을 것입니다. 실험 결과 스파크벤치의 그래프 연산 워크로드인 svd++를 타겟으로 삼았습니다. The plan of our work is looking for some real workload that share the features with our validation program. The features are as follows the workload should have high memory usage as well as high locality. As a result, we chose SVD++ as our target workload.
• #9 다음 두가지 그래프는 svd++를 타겟으로 삼은 구체적인 이유입니다. 다른 워크로드들에 비했을 때, svd++는 적은 페이지폴트에 비해 메모리 사용량이 많으며 이는 액세스 로컬리티가 높다는 것을 의미합니다. 검증프로그램과 유사하므로 사용하는것이 적합할것. 또한, 워크로드를 코드레벨로 확인하여 검증 프로그램과의 유사성을 비교해보려합니다. These two pics shows the reason why we chose SVD++ as our target workload. Comparing with others, it as higher memory access rate and with fewer page faults, which means high access locality We are going analyze the its code to verify whether it does share the common features with our validation program. If so, we are going to choose this program as our evaluation baseline.
• #10 본문 내용은 여기까지이며, 결론을 말씀드리자면, 현재 JVM GC 정책이 스왑에 대한 정보를 고려하지 않는다는 문제가 있어 이 문제를 해결하기 위해 두 가지 방법을 제안하였고 이를 검증하기 위해 실제 워크로드의 특성을 분석하였습니다. 앞으로는, 제안한 방법을 구현하고 선택한 타겟 워크로드에 대해 그 성능을 평가해볼 계획입니다. 발표마치겠습니다~~~ 감사합니다~~~ Here is the conclusion, we found out the problem that current JVM GC policy does not take system swap information into consideration. Then aiming to solve this problem ,we proposed 2 solutions and select one real workload that has the similar features with our validation program. We plan to implement our solutions and evaluate them on our selected target workload.
• #11 Our research is about designing a new JVM garbage collection policy , which should suppose to be decrease the overhead caused by LINUX system SWAP.