1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
# 028 — 고정 네이티브 앱의 불변 프로그램 공유
2026-09-24. Linux AArch64, Zig 0.15.2, GCC 14.2. 첫 공개 체크포인트의 중간 결과다.
마이크로 런타임의 기본 비용을 지키기 위해, **같은 정의로 실행하는 독립 인스턴스의 반복
메모리에서 프로그램·교체 공간·선택형 캐시를 제거했다.** 코어의 기능이나 의존성을 늘리지 않았다.
## 구조와 경계
[027의 고정 용량 빌드](027-fixed-native-capacity.md)는 최대 예약을 줄였지만, 한 앱의
명령·반응·대상 정보와 교체 준비 공간을 인스턴스마다 보유했다. CLI·피어는 정의를 실행 중
교체하지 않으므로 준비 단계가 만든 동일한 정의를 Zig 빌드의 불변 `Program`으로 한 번
링크한다. 인스턴스에는 설치 여부, 각자의 상태·진단·평가 기록만 남긴다. 고정 빌드에서
C의 명령·반응 배열도 다시 링크하지 않는다.
```text
작성된 .pure → 기존 준비기 → 고정 빌드의 불변 Program (앱마다 한 벌)
├─ scalar 인스턴스 A: 상태·진단·평가
└─ scalar 인스턴스 B: 상태·진단·평가
```
설치할 때 준비 정의의 SHA-256 identity와 상태·입력·명령·반응·대상 개수를 빌드 정의와
대조한다. 복원 값은 모두 유한한지 확인한 뒤에야 상태·버전을 바꾼다. 여기서 identity는
저장 상태의 **호환성 검사**이며 출처 인증이 아니다. 고정 실행물에서 다른 정의를 쓰려면
재빌드해야 한다. 정의 staging API와 선택형 평가 캐시는 이 프로필에서 용량 오류를 반환한다.
캐시 없는 평가와 정해진 작업 예산은 계속 사용한다. 정의 교체가 필요한 GTK 작성 창과
브라우저 Wasm은 일반 프로필을 유지한다.
초기 버전에는 설치 전의 빈 상태를 표현하려고 2,480 B짜리 빈 `Program`이 실행 파일에
추가로 들어갔고, 기본 포인터 초기값은 읽기 전용 영역의 동적 재배치도 만들었다.
최종 버전은 인스턴스의 설치 여부로 빈 상태를 표현한다. [실행물 의존성 검사](../../prototypes/workbench/results/2026-09-24-shared-program/dependencies.txt)에서
CLI·피어 모두 `TEXTREL`이 없고, [심볼 검사](../../prototypes/workbench/results/2026-09-24-shared-program/symbols.txt)에서
2,480 B `engine.shared_program` 한 벌만 남은 것을 확인했다.
## 반복 비용과 동작
`routed-layout.pure`의 [최종 크기·RSS 원자료](../../prototypes/workbench/results/2026-09-24-shared-program/instance-memory.json):
| 범위 | 일반 작성 프로필 | 앞선 고정 용량 [027](027-fixed-native-capacity.md) | 공유 고정 프로필 |
|---|---:|---:|---:|
| scalar 인스턴스 요구 저장 공간 | 20,064 B | 5,456 B | **280 B** |
| 같은 scalar 인스턴스 1,000개 초기화의 RSS 증가, 3회 중앙값 | 19,808 KiB | 5,536 KiB | **480 KiB** |
각 인스턴스를 실제 할당·초기화·설치한 뒤 버전 합을 검사했다. RSS는 Linux의 초기화
전후 차이이며 allocator·페이지 단위의 영향도 포함한다. 이 값은 **scalar 인스턴스
반복 비용**이지 사용자 1,000명의 서비스 메모리·처리량이나 전체 피크가 아니다.
고정 프로그램 자체는 앱마다 정적 저장 공간 2,480 B를 한 번 사용한다. 별도의 C 앱
컨트롤러는 이 사례에서 928 B이고, 저장·입출력·스택·TLS·GTK는 위 280 B에 없다.
[고정 프로필](../../prototypes/workbench/results/2026-09-24-shared-program/fixed-parity.json)과
[일반 프로필](../../prototypes/workbench/results/2026-09-24-shared-program/general-parity.json)은
기존 작성물 11개, 입력 170단계의 상태·출력을 Wasm과 비교했다. 두 C 호스트는 ASan/UBSan,
Zig 모듈은 ReleaseSafe였다. 고정 단위 검사는 독립 상태, 설치 전 빈 상태, 잘못된 정의
identity·개수 거부, 복원 실패의 원자성, 부호 있는 0과 reset을 확인했다. 일반 프로필의
정의 staging·교체 검사도 통과했다. Zig 코어 37개와 브라우저/CLI 회귀 87개를 통과했다.
## 선택한 실행물의 비용
같은 `routed-layout.pure`, C `-O2 -g`의 [섹션 크기](../../prototypes/workbench/results/2026-09-24-shared-program/size.txt),
[stripped 파일 크기](../../prototypes/workbench/results/2026-09-24-shared-program/stripped.txt),
[CLI 빌드 식별](../../prototypes/workbench/results/2026-09-24-shared-program/cli-build.json),
[피어 빌드 식별](../../prototypes/workbench/results/2026-09-24-shared-program/peer-build.json).
| 선택한 범위 | 앞선 고정 용량 [027](027-fixed-native-capacity.md) | 공유 고정 프로필 |
|---|---:|---:|
| scalar 오브젝트 `text` | 18,252 B | **10,396 B** |
| CLI 실행물 `text` | 48,059 B | **37,135 B** |
| CLI stripped ELF | 68,000 B | **68,000 B** |
| TLS 피어 실행물 `text` | 61,201 B | **50,277 B** |
| TLS 피어 stripped ELF | 68,400 B | **68,400 B** |
이 호스트의 ELF 배치·정렬 때문에 이번에는 **stripped 파일 크기가 줄지 않았다**.
CLI는 libc, 피어는 libc·OpenSSL 동적 라이브러리를 요구한다. 피어의 유휴 RSS는
[최종 인증·복원·오류 검사](../../prototypes/workbench/results/2026-09-24-shared-program/peer-check.json)에서
7,856 KiB였다. 공통 저장 실행 코어의 별도 `text` 예산 5,932 B는 그대로 통과했다.
이제 작은 scalar 인스턴스만 더 줄이는 측정은 우선순위가 아니다. 첫 공개 체크포인트에는
실제 크기의 작성·저장·원격 작업을 포함한 **앱 전체 비용과 실패 조건**이 필요하다.
이번 결과는 반복 메모리 제거와 기존 동작 유지의 증거이며 큰 서비스의 지연·처리량 우위나
macOS 메모리 특성에 대한 증거는 아니다.
|
