Program Execution 전체 지도 지금까지 Source Code가 Compile되고, Link되고, Process가 되어 Memory에 배치되고, 필요할 때 Kernel Service를 요청하는 흐름을 따라왔다. 마지막에는 결국 CPU가 Machine Code를 실행한다. Compiler가 만든 Machine Code는 CPU 안...

Program Execution 전체 지도 지금까지는 Native Program을 기준으로 Compile, Link, Load, Process, Virtual Memory, System Call을 따라왔다. 그런데 Java, Go, JavaScript, WebAssembly를 보면 실행 구조가 서로 다르다. Runtime이 있다는 말은 정확...

Program Execution 전체 지도 앞선 글에서는 Application이 System Call을 통해 Kernel Service를 요청하는 경계를 살펴봤다. 그런데 Compiler가 만든 Code, Library, 운영체제는 서로 따로 만들어질 수 있다. 서로 다른 Binary는 Argument 위치, Return Value, Dat...

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

Program Execution 전체 지도 앞선 글에서는 실행 파일이 Loader를 거쳐 Process가 되는 흐름을 살펴봤다. Process가 만들어지면 다음 질문이 생긴다. 프로그램이 사용하는 주소는 실제 RAM의 어느 위치를 가리키는가? 처음에는 Process가 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를 언제 선택할지 정리한다.