IBM JVM 소개 - Oracle JVM 과 비교

1
SoftwareGroup WebSphere
Confidential - Do Not Distribute
2017.
IBM Hybrid Cloud Technical Sales
이정운 차장 (JungWoon Lee, juwlee@kr.ibm.com)
© Copyright IBM Corporation 2017
Cloud, IBM Korea
IBM JVM 소개

2
JVM(Java Virtual Machnine)
 JVM 은 Java Bytecode 를 실행할 수 있는 주체이다. Java Bytecode 는 플랫폼에 독립적이며 모든 JVM 은 JVM 규격에 정의된
대로 Java Bytecode 를 실행한다. 따라서 표준 자바 API까지 동일한 동작을 하도록 구현한 상태에서는 이론적으로 모든 Java 프
로그램은 CPU나 운영 체제의 종류와 무관하게 동일하게 동작할 것을 보장한다.
 Java Platform (JRE) : Java VM + 표준 Java 라이브러리
 Java VM : Load & Execute Java binary(.class format)
 세 개의 핵심 Component
– ClassLoader
• Java binary load + Runtime data 로의 변환
• Loader, Linker
– Execution Engine
• Bytecode 실행 + Native로의 연결
• Interpreter, Compiler
– VM Runtime
• VM이 갖고 있는 data 및 그 관리자
• Heap (GC), Thread, Lock

3
 JVM 의 실행시간 데이터 영역은 다시 세부적으로 메소드 영역, 힙 영역, 스택 영역, PC 레지스터, Native 메소
드 스택으로 나뉘어 집니다.
클래스 로더
메소드(method)
영역
-메소드의
바이트코드
-클래스 변수
힙(heap) 영역
-객체
스택(stack) 영역
-매개변수
-지역변수
PC 레지스터 Native 메소드
스택
실행 엔진 Native 메소드 인터페이스
실행시간 데이터 영역(Runtime data area)
클래스 파일
Native 메소드
라이브러리
클래스
라이브러리

4
 샘플 자바 소스의 실행시의 JVM 메소드 영역, 스택 영역, 힙 영역의 메모리 모델 예제
메소드 영역
스택 영역 힙 영역
main() 메소드
바이트 코드
args null
main
frame
a
5 6 7 8
b
b[2]
b[1]
b[0]
1 2 3
4 5
96 7 8
s1
s2
“Hi Java”
s2[1]
s2[0]
“Java”
“Hi”
 샘플 자바 소스
class MemoryTest3 {
public static void main(String[] args)
{ int a[] = new int[] {1,2,3};
a = new int[] {5,6,7,8};
System.out.println(a[3]);
int b[][] = new int[][] {{1,2,3},{4,5},{6,7,8,9}};
System.out.println(b[2][3]);
String s1 = "Hi Java";
System.out.println(s1);
String s2[] = new String[] {"Hi","Java"};
System.out.println(s2[1]);
} }

5
그럼, IBM JVM 과
Oracle 의 JVM 은
동일한가요?

6
IBM SDK for Java
 IBM SDK for Java 는 Oracle Platform Java Standard Edition (Java SE) 8 application programming interfaces
(APIs) 완벽한 호환성을 제공합니다.
• Generalized Target-Type Inference JEP 101
• Parallel Array Sorting JEP 103
• Annotations on Java Types JEP 104
• DocTree API JEP 105
• ……
• Enhance the Certificate Revocation-Checking API JEP 124
• Lambda Expressions & Virtual Extension Methods JEP 126
• ……
• PKCS#11 Crypto Provider for 64-bit Windows JEP 131
• Unicode 6.2 JEP 133
• Base64 Encoding & Decoding JEP 135
• Date & Time API JEP 150
• ……
• Concurrency Updates JEP 155
• Prepare for Modularization JEP 162
• Leverage CPU Instructions for AES Cryptography JEP 164
• JDBC 4.2 JEP 170
• ……

7
Oracle 과 IBM Java 의 주요 차이점
 IBM 과 Oracle Java 는 모두 Java Class Libraries 에 대한 같은 참조 구현체를 사용하지만 JVM 런타임은 각자
다른 형태로 구현하였습니다.
 IBM and Oracle use the same reference implementation of Java Class Libraries (e.g. OpenJDK)
• Key differences to be aware of:
- Security: Standards do not impose strong separation of interest
- ORB: OMG CORBA standard rules
- XML: Xerces/Xalan used by both vendors as of Java 5, although different levels may be used.
 IBM uses the J9/TR runtime, Oracle uses Hotspot
• Different JIT/GC/VM tuning and controls
• Tooling is distinct (e.g. IBM’s Health Center)

8
IBM JVM
 IBM JVM 인 J9 은 IBM 에서 디자인된 가상 머신으로 고성능, 고가용성, 높은 서비스 제공을 목적으로 제작되
었습니다.
 IBM’s strategic virtual machine : J9
• Designed from the ground up by IBM
• Focused on high performance , high reliability and serviceability
• Scales from embedded and handheld devices to large SMPs
• Highly configurable with pluggable interfaces for alternative implementations of GC, JIT
 Composed of several key components
• Reconfigurable, portable virtual machine framework and interpreter called “J9”
• Type accurate garbage collection frameworks (Modron, Tarok, Metronome)
• Highly optimizing just-in-time (JIT) compiler “Testarossa”
• Integrated RAS features to enhance problem determination
• Unique Features - SharedClasses, Dynamic AOT

9
Java Adaptive Compilation : trade off effort and benefit
 IBM JVM 은 고도로 최적화 가능한 just-in-time (JIT) compiler 를 통해서 runtime profiling 기반으로
bytecode 에 대한 컴파일을 수행합니다.
 Java's bytecodes are compiled as required, optimized based on runtime profiling
• Dynamic compilation determines the target machine capabilities and app demands
• Multiple phases, enable adaptive response to changing environment
cold
hot
scorching
profiling
interpreter
warm
 Methods start out running bytecode form directly
 After many invocations (or via sampling) code get compiled at ‘
cold’ or ‘warm’ level
 Low overhead sampling thread is used to identify hot methods
 Methods may get recompiled at ‘hot’ or ‘scorching’ levels (for m
ore optimizations)
 Transition to ‘scorching’ goes through a temporary profiling step
Results can be stored for future runs and shared across invocations

10
Shared Classes Cache
 IBM JVM 은 Shared Classes Cache 를 활용하여 메모리 소모 감소와 시작시간의 비용을 줄일 수 있도록 설계
되어 있습니다.
 IBM JVMs use sharing to reduce memory and startup costs
• Ability to securely common Java class code across multiple JVM instances
• Reduces footprint due to sharing of read-only components (Java code)
• Reduces startup time by caching “ready to run” previously JITed code (Dynamic AOT)
• Dynamic AOT - reuse JIT code from multiple JVMs
• Reduce memory use by 20%, improve startup time 10-30 %
JVM
JVM
JVM
JVM
JVM
Shared Classes Cache
JVM
JVM
JVM
JVM
JVM
JVM
JVM
JVM
JVM
JVM
AOT – Ahead Of Time
(JIT code saved for next JVM)
Verified bytecodes
JVM shared index
“Compile once,
run manywhere”

11
그럼, IBM JVM 과
Oracle JVM 의
Heap 구조는 동일한가요?

12
Oracle JVM 의 Heap 구조
 Oracle JVM 은 Heap 영역을 세대별로 나누어서 관리하는 방식을 사용합니다. (Java 8.0 부터는 Perm 영역이
없어지고 Metaspace 사용)
 Oracle JVM 이 사용하는 Heap 구조 (Hotspot)
 Permanent Space : Class에 대한Meta 정보를저장하는 공간
- Method of a class(including the bytecodes)
- Names of the classes
- Constant pool 정보
- JVM으로부터 만들어진 내부 객체 ex: java/lang/Object
 New Generation
- Eden: 새로(new) 생긴 모든객체
- Survivor1(SS1)
> Minor GC에의해서 Eden, Survivor 2영역의객체 중 활성화된객체만 이동하여 위치
> Old Space로이동되기 전의 객체만위치
- Survivor 2(SS2)
> Minor GC에의해서 Eden, Survivor 1영역의객체 중 활성화된객체만 이동하여 위치
> Old Space로이동되기 전의 객체만위치
 Old Generation
- Survivor 1, Survivor 2 영역에서이동해온 객체만 위치
- Full GC의대상이 되는 객체가 위치

13
Oracle JVM 의 Heap 구조
 Oracle JVM 은 Heap 영역을 세대별로 나누어서 관리하는 방식을 사용합니다. (Java 8.0 부터는 Perm 영역이
없어지고 Metaspace 사용)

14
IBM JVM 의 Heap 구조
 IBM JVM 은 이전부터 Oracle 과 다르게 Heap 을 구분하지 않고 single heap 구조를 사용하다가 IBM JVM
5.0 이후 부터 옵션을 통하여 Heap 영역의 구분 방식을 변경할 수 있는 방법을 제공합니다.
 IBM JVM 이 사용하는 Heap 구조 (IBM JVM 1.4.2 이전)
 IBM JVM 이 사용하는 Heap 구조 (IBM JVM 5.0 이후 – 기본 모드)
 IBM JVM 이 사용하는 Heap 구조 (IBM JVM 6.0 이후 – gencon 기본 모드)

15
 IBM JVM 은 Java 6.0 부터 gencon 정책이 GC 기본 정책이 되었고 Oracle JVM Heap 과 비슷하면서도 다른
구조를 가지게 되었습니다.
 Oracle JVM Heap 구조와 비교
IBM JVM:
-Xmn (-Xmns/-Xmnx)
Sun:
-XX:NewSize=nn
-XX:MaxNewSize=nn
-Xmn<size>
Sun JVM Only:
-XX:MaxPermSize=nn
Nursery/Young Generation Tenured/Old Generation Permanent Space
JVM Heap
IBM JVM:
-Xmo (-Xmos/-Xmox)
Sun:
-XX:NewRatio=n
 각 JVM 지원 운영체제
- IBM JVMs – Windows, AIX, Linux(x86 and PPC), i5/OS, z/OS
- Oracle HotSpot based JVMs
> Oracle HotSpot JVM on Solaris
> HP’s JVM for HP-UX

16
 IBM JVM 5.0 버전이후로 pCluster, kCluster 가 없어지는 대신에 해당 영역에 자리잡던 것들이 native 영역에
위치하게 됩니다. (Oracle 의 Metaspace 랑 비슷하게 이해하시면 됩니다. 단, 완벽히 동일하지는 않습니다.)
Java Object 연관된 Native 자원
Thread objects Native Thread
AWT objects Widgets/Shells
Socket objects Native Socket
Class objects Class structure, Constant Pool, Method Table,
Method Blocks, Compiled Code
Class Loader Class cache
Constraint Table
 Java Objects 들의 underpin(토대,지지) 을 위한 자원
 Class Object 의 native heap 사용

17
IBM JVM 의 GC 정책
 IBM JVM에서는 4가지 방식의 GC 방법을 제공하므로 원하는 목적에 맞는 GC 방식을 선택해서 사용할 수 있
습니다. (이 GC 방식의 변경에 따라서 Heap 의 구조도 변경됨)
 GC 정책 (-Xgcpolicy 옵션 이용)
항 목 설 명 비고
Optthruput 정책
처리량은 높지만 GC 중간시간이 길다.
GC 중 compaction 이 필요하면 mark, sweep, compaction 을 하기
위한 모든 어플리케이션 thread 는 중지된다.
Java 5.0 까지의 기본값
Optavgpause 정책
어플리케이션 실행과 함께 GC의 mark, sweep 단계를
실행시킴으로써 GC 중단 시간을 줄인다. 이런 동시실행은 전반적인
처리량에 작은 성능 영향을 야기할 수 있다.
Gencon 정책
IBM JVM 을 위하여 세대가 있는 GC를 사용한다.
세대의 개념은 GC 중단시간을 줄임으로써 높은 처리량을 달성하기
위해 사용된다. 이러한 목적을 이루기 위하여 heap 을 new 와 old
부분으로 나눈다. 짧게 살아있는 객체가 new영역에서 빠르게 GC
되는 반면에 오랫동안 살아있는 객체는 old 공간으로 이동한다.
Java 5.0 이후 새로 도입된
정책으로 짧은 주기의 객체사용의
경우 성능상에 많은 이점이
있습니다. (Java 6.0.1 이후 기본값)
Balanced 정책
일반적으로 4GB 이상의 Large Heap 을 사용할 경우에 효과가 높음
Large Heap 을 일정정도의 작은 단위인 region 으로 나누어서 해당
단위 기준으로 GC 가 수행됨(gencon 과 동일)
Global GC 에 의한 long pause time 이슈를 줄일 수 있으며 보다
일관된 pause time 제공 가능

18
Time
Thread 1
Thread 2
Thread 3
Thread n
GC
Application
 -Xgcpolicy:optthruput
 처리량이 짧은 GC 일시 중지보다 더 중요한 응용 프로그램에 사용
Time
Application
Thread 1
Thread 2
Thread 3
Thread n
GC
Concurrent
Tracing
 -Xgcpolicy:optavgpause
 가비지 콜렉션을 동시에 수행하여 짧은 GC 중단 시간 동안 높은 처리량을 처리 (일시 중지 최소화)

19
 -Xgcpolicy:gencon
 수명이 긴 Object 보다 수명이 짧은 Object 를 다르게 처리합니다. 수명이 짧은 Object 가 많은 응용 프로그램은 이
정책을 사용하여 일시 중지 시간을 줄이는 동시에 우수한 처리량을 제공합니다.
 -Xgcpolicy:balanced
 Large Heap 에서 최대 일시정지 시간을 줄이고 가비지 콜렉션의 효율성을 향상시키기 위해 개별적으로 관리
Time
Global GC
Application
Concurrent
Tracing
Thread 1
Thread 2
Thread 3
Thread n

20
IBM JVM 의 기본 제공 모니터링 도구
 IBM JVM 은 보다 안정적인 운영을 위하여 기본적으로 Health Center, GCMV, Memory Analyzer 등을 무상으
로 제공하고 있습니다.
Memory Analyzer
-Heapdump 나 IBM System dump를 분석하는 도구
-메모리 누수 감지 및 풋프린트 분석 제공
-실제 Java Heap의 점유 클래스를 그래프적으로 표현
Health Center
-매우 적은 오버헤드를 가진 모니터링 도구
-메소드 프로파일링, GC, class loading, locking에 대한 분석
데이터 제공
-권고와 함께 잠재적 문제 가능성 진단 가능
Garbage Collection and Memory Visualizer
-Java verbose GC logs를 분석하는 도구
-성능 제한이 발생하는 이슈에 대하여 그래프적인 가이드
제공
-GC와 Java Heap 통계 정보 및 성능 튜닝 권고 리포팅

21
End of The Document.

IBM JVM 소개 - Oracle JVM 과 비교

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie IBM JVM 소개 - Oracle JVM 과 비교

Ähnlich wie IBM JVM 소개 - Oracle JVM 과 비교 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (8)

IBM JVM 소개 - Oracle JVM 과 비교