JVM

모든 객체에 대해 메모리의 할당/해제를 책임져야 하는 C/C++ 과 달리 Java JVM 의 장점은 메모리 관리를 자동으로 해준다는 것이다.이는 반대로 자동으로 해주는 JVM 의 메모리 관리를 잘 알지 못하면, 메모리에 문제가 생겼을때 대처하기 힘들다.JVM 가 사용하

한번 작성하면 어디든 실행된다.메모리 관리를 자동으로 해준다.핫 코드를 감지하고 컴파일 및 최적화하여 성능을 높인다.우리가 자바를 쓰는 이유들이다.JDK 는 자바 프로그래밍 언어, JVM, 자바 클래스 라이브러리를 묶어 부르는 말이며, 이는 자바 프로그램 개발에 필요한

HotSpot 기준으로 객체가 메모리에서 어떻게, 어떤 형태로 생성되며 어떻게 참조될까. 객체 생성 객체를 생성하려면 클래스 로딩이 안되어 있으면 로딩 후에 메모리를 할당하고, 메모리 공간을 0으로 초기화한 뒤, 객체 해더값을 채우고, 생성자를 실행한다. 이 모든

oop(https://github.com/openjdk/jdk/blob/6c48f4ed707bf0b15f9b6098de30db8aae6fa40f/src/hotspot/share/oops/oopsHierarchy.hpp이 포인터가 가리키는 객체는 oopDesc(

GC 와 메모리 할당 내부를 자세히 알아야 하는 이유가 무엇일까.메모리 오버플로 누수 문제를 해결하거나, 높은 동시성을 달성할 때 GC 가 문제가 될때자동화된 GC 모니터링을 통해 이를 조율할 수 있어야 하기 때문이다.프로그램 카운터, 가상머신 스택, 네이티브 메서드

루트 노드 열거 - oopMap 루트 노드 열거는 루트객체로부터 참조체인을 검색하여 가비지 객체를 선별하는 과정이다. 가비지 컬렉션이 될 수 있는 위치는 메모리 공간 즉 힙과 메서드 영역. 따라서 Root GC 가 될 수 있는 영역은 크게 스택과 메서드 영역. 목

Garbage Collector 의 성능은 처리량(Throughput), 지연 시간(Latency), 메모리 사용량(footprint) 세가지 요소로 측정된다. 이 세가지는 모두 만족시키기 어렵다.Garbage Collector 를 알아볼때에는 각 컬렉터들이 어떤 성능

CMS 는 가비지 컬렉션 일시 중지 시간을 최소화하고, 애플리케이션 실행 중에 가비지 컬렉터와 프로세서 리소스를 공유할 수 있는 애플리케이션을 위해 설계되었습니다. 일반적으로 장기간 보존되는 데이터(tenured 크기가 큰 경우)가 비교적 많고 프로세서가 두 개 이상인

G1 GC > 대용량 메모리를 갖춘 멀티프로세서 시스템을 대상으로 합니다. G1은 최소한의 설정으로 높은 처리량을 달성하면서 가비지 컬렉션 일시 중지 시간 목표를 높은 확률로 충족하도록 설계되었습니다. G1은 다음과 같은 특징을 가진 현재의 대상 애플리케이션 및 환경을

GC 는 처리량, 메모리 사용량, 지연 시간 세가지 지표가 있다. 처리량과 메모리 사용량은 하드웨어가 발전하며 좋은 지표를 내기 쉽지만, 지연 시간은 그렇지 않다. 더 많은 용량의 RAM 이 개발될 수록 GC 를 위한 시간은 점점 더 멀어진다. 따라서 GC 는 지연

JVM 이 플랫폼 독립이 될 수 있었던 이유는 클래스 파일 덕분이다.JVM 은 클래스 파일을 해석하여 실행하는 머신이고, 자바는 클래스 파일을 만들 수 있는 언어 중 하나다.과거에는 리눅스, 윈도우 등 플랫폼에 독립적으로 아무 곳에서 작성해도 실행할 수 있는 것 이었지

클래스 파일의 Code Attribute 에 순서대로 나열되는 바이트 코드 명령어는 u1 타입이기에 총 256 개의 명령어를 나타낼 수 있다.현재는 200개 넘는 수의 바이트 코드 명령어가 있다.클래스 파일에 \[바이트 코드 명령어] + \[필요시 피연산자] 형태로 작

C언어는 컴파일 시점에 심벌 참조(논리적인 참조)를 직접 참조(실제 메모리 주소)로 변환하는 링킹 과정을 실행한다. 컴파일 단계에서 실제 호출 대상이나 코드 실행 전략 등이 고정된다.반면 자바는 컴파일시 심벌 참조만 가진 클래스 파일을 만든다. JVM 런타임에 이 심벌

클래스 로딩 단계 중 첫번째 로딩 단계 중 완전한 이름을 보고 해당 클래스를 정의하는 바이너리 바이트 스트림 가져오기 는 ClassLoader 라는 JVM 외부 컴포넌트에서 이뤄진다.이는 JVM 설계 의도이다. JVM 설계자들은 이 행동이 외부에서 이뤄져서 JVM 과

메서드는 JVM 의 기본 실행 단위이다.하나의 메서드가 실행될 때 JVM 은 내부적으로 스택 프레임 이라는 데이터 구조를 사용한다.하나의 스택 프레임 내부에는 하나의 메서드를 실행시키기 위한 데이터들이 저장된다.컴파일 시점에 지역 변수 테이블과 피연산자 스택이 필요로하

이번 글의 내용은 메서드 내용의 실행이 아닌 메서드의 호출이다. 컴파일된 클래스 파일에는 호출할 메서드의 이름(FQCN)이 적혀있다. JVM 런타임에는 해당 이름의 메서드는 여러개가 존재할 수 있다. (오버라이딩, 오버로딩) 클래스 파일의 단순 이름인 심벌 참조를

동적 타입 언어 : 타입 검사 과정 중 주요 단계들이 런타임에 수행 : 자바스크립트 타입 검사를 컴파일 타임에 수행하는 언어는 정적 타입 언어 : java, c++

javac 명령어로 java 파일 -> class 파일 작업하는 것을 컴파일이라 한다.이 컴파일은 위와 같은 단계로 이뤄진다.실제 코드레벨로는 com.sun.tools.javac.main.JavaCompiler어휘 분석 : int a = b + 2 와 같은 코드를 in

javac 컴파일의 편의문법 제거 대상인 제네릭과 개발자의 코드 추가 로직인 애너테이션 프로세서에 대해 알아보자.배열은 공변이다. String 이 Object 의 하위 타입이라면 String\[] 도 Object\[] 의 하위 타입이다.따라서 Object\[] 정적 타

JIT 컴파일러, AOT 컴파일러둘 다 자바 가상 머신 명세상 필수는 아니지만 성능상 꼭 필요하다.Hotspot 은 기본적으로 인터프리터로 실행자주 실행되는 코드(Hotspot) 을 JIT 로 컴파일 하여 네이티브 코드로 실행인터프리터프로그램을 빨리 실행해야할 때가용

컴파일러의 이름은 네이티브 코드로 바꾼다는 것이지만, 이게 중요한게 아니다.네이티브 코드로 바꿀 때 얼마나 효율적인 코드로 최적화할 수 있냐 가 컴파일러의 품질을 결정한다.JIT 컴파일러는 컴파일 과정에서 LIR, HIR 을 대상으로 여러가지 최적화를 진행한다.http

프로그램 실행(런타임) 이전에 최적화(C1, C2) 와 네이티브 코드 생성(인터프리터, C1, C2)를 미리 하여 런타임에는 바이트코드를 바로 실행하게 할 수 있다.미리 자바 코드로 부터 네이티브 코드를 만드는 컴파일러르 AOT 컴파일러라 한다.java 진영에서는 크게

Jaotc 는 JDK 9 ~ JDK 16 에 포함된 JDK AOT 컴파일러이다.JEP 295 에서 제안되었으며 JEP 410 에서 사라졌다.와 같이 미리 AOT 컴파일러로 so 파일을 만들고,와 같이 실행할 수 있다.하지만 JEP 295 에도 적혀 있듯, 아무도 쓰지도

컴퓨터가 점점 빨라지며 상대적으로 I/O 시간은 점점 느려지고 있다. 따라서 빠른 속도의 CPU 를 효율적으로 사용하는 멀티스레딩은 필수적인 기술이다. 하지만 프로세스, 스레드들이 공유하는 메모리의 데이터는 동시성 문제라는 것을 해결해야 한다. 하드웨어에서의 동시성

OS 가 제공하는 커널 스레드(커널의 복제본) 한개를 고수준 인터페이스인 경량 프로세스(스레드) 하나로 맵핑하여 사용커널의 도움으로 경량 프로세스 각각이 독립적으로 스케줄링 된다. 따라서 경량 스레드 하나가 시스템 호출에서 블록되더라도 전체 프로세스는 영향을 받지 않는

여러 스레드가 한 객체에 동시에 접근할 때 어떤 런타임 환경에서든 다음 두 조건을 모두 충족하면서 객체를 호출하는 행위가 올바른 결과를 얻을 수 있다면 그 객체는 스레드 안전하다 라고 한다.특별한 스레드 스케줄링이나 대체 실행 수단을 고려할 필요가 없다추가적인 동기화