Program Execution 전체 지도 지금까지 소스 코드가 컴파일되고, 링크되고, 프로세스가 되어 메모리에 배치되고, 필요할 때 커널 Service를 요청하는 흐름을 따라왔다. 마지막에는 결국 CPU가 Machine 코드를 실행한다. 컴파일러가 만든 Machine 코드는 CPU 안에서 실제로 어떻게 실행되는가? 1. 소스 코드와 ...

Program Execution 전체 지도 지금까지는 네이티브 프로그램을 기준으로 컴파일, 링크, Load, 프로세스, 가상 메모리, System Call을 따라왔다. 그런데 Java, Go, JavaScript, WebAssembly를 보면 실행 구조가 서로 다르다. Runtime이 있다는 말은 정확히 무엇이며, 언어마다 Runtime은 ...

Program Execution 전체 지도 앞선 글에서는 애플리케이션이 System Call을 통해 커널 Service를 요청하는 경계를 살펴봤다. 그런데 컴파일러가 만든 코드, 라이브러리, 운영체제는 서로 따로 만들어질 수 있다. 서로 다른 바이너리는 인자 위치, 반환값, Data 배치 같은 약속을 어떻게 맞출까? 이 바이너리 수준의 ...

Program Execution 전체 지도 앞선 글까지는 프로그램의 코드와 Data가 어떻게 CPU와 메모리에서 실행 가능한 상태가 되는지 살펴봤다. 하지만 실제 프로그램은 계산만 하지 않는다. 파일을 읽는다 네트워크로 데이터를 보낸다 새 Process를 만든다 시간을 확인한다 Device를 사용한다 이런 자원은 운영체제가 관리한다. 그래...

Program Execution 전체 지도 앞선 글에서는 실행 파일이 Loader를 거쳐 프로세스가 되는 흐름을 살펴봤다. 프로세스가 만들어지면 다음 질문이 생긴다. 프로그램이 사용하는 주소는 실제 RAM의 어느 위치를 가리키는가? 처음에는 프로세스가 RAM의 특정 영역을 직접 사용하는 것처럼 생각하기 쉽다. 현대 운영체제에서는 보통 ...

Program Execution 전체 지도 앞선 글에서는 소스 코드가 컴파일과 링크를 거쳐 실행 파일이 되는 과정을 살펴봤다. 그런데 실행 파일이 만들어졌다고 프로그램이 실행 중인 것은 아니다. 디스크에 있는 실행 파일을 실행하면, 운영체제는 무엇을 해서 그것을 프로세스로 만드는가? 이번 글에서는 이 경계를 따라간다. 1. 실행 파일...

Program Execution 전체 지도 앞선 글에서는 프로그램이 실행되는 전체 흐름을 살펴봤다. 이번에는 그중 앞부분인 소스 코드가 실행 파일이 되기까지를 조금 더 자세히 살펴본다. 핵심 질문은 하나다. 왜 소스 코드를 컴파일하는 것만으로 끝나지 않고, 오브젝트 파일과 링커라는 단계가 따로 필요한가? Source Code ...

코드를 작성하고 실행 버튼을 누르면 프로그램이 실행된다. 평소에는 이 과정을 당연하게 사용하지만, 그 사이에는 생각보다 많은 계층이 존재한다. Source Code ↓ Compiler ↓ Object File / Bytecode ↓ Linker ↓ Executable ↓ Loader ↓ Process ...

WebAssembly(Wasm)를 처음 접했을 때 가장 먼저 든 의문은 단순했다. JavaScript가 있는데 굳이 새로운 실행 방식을 만들 필요가 있었을까? 브라우저는 이미 JavaScript를 실행할 수 있다. JavaScript 역시 사용자의 CPU와 메모리를 사용한다. 그렇다면 WebAssembly가 해결하려던 문제는 무엇이었을까? ...

JPA에서 문자열·날짜·DB 전용 함수를 표현하는 여러 방법을 비교하고, JPQL 표준 함수, DB 함수 호출, Repository 확장, QueryDSL, Criteria API, Native Query를 언제 선택할지 정리한다.