[rustjava-error-path-needs-java-lang-string-measure-first] fix(jvm): 오류 경로의 또 하나 java/lang/String — 재귀한다, 그래서 생성 시점에 막는다

[Jun025]

채택 제안 2026-09-19-fallback-class-absence-fails-at-construction#p0 이행.
★제안의 조건이 「측정이 먼저」였고 그대로 했다 — assert 를 먼저 넣지 않고 하니스로 쟀다.

답 = ⒜ 재귀한다 (⒝ 깨끗한 실패도, ⒞ 이미 상주도 아니다)

give_up_after	결과
5 · 20 · 60	생존 — 구성이 평범한 NoClassDefFoundError 로 끝난다
116	생존 (2회 재현)
117	★ fatal runtime error: stack overflow, aborting — SIGABRT · rc 134 (2회 재현)
120 · 160 · 200	abort
100000	abort ⇒ ★상한은 «하니스가 양보하는 지점»이지 바닥이 아니다

생존 60 ↔ abort 120 사이 이분법으로 찾았다. 경계가 날카롭고 결정론적이다.

⒞가 아닌 이유 — 구조로

• bootstrap_classes 는 6개(Object·Runnable·Thread·[B·Serializable·Class) · ★String 없음
• JavaLangClass::from_rust_class 는 이름을 [B(nameBytes) 로 넣지 String 으로 넣지 않는다
• ⇒ 구성 중 String 을 처음 필요로 하는 곳은 프로퍼티 루프이고, 그때 로더가 유일한 출처다

처방 — 자리가 장식이 아니다

기존 NoClassDefFoundError 확인과 같은 관용(로더에 직접 질의 → resolve).
★bare resolve_class 는 답이 안 된다 — 실패를 Jvm::exception 에 넘기는데 그것이 곧 순환이다.
★프로퍼티 루프 «앞» 에 둔다. 기존 확인은 그 루프 뒤라 String 형상은 거기 닿기 전에 재귀한다.

양방향 축 (제품 호출부 jvm/src/jvm.rs · 픽스처 사본 아님)

형상	결과
원형상	green — 2 passed
확인 제거	★ stack overflow, aborting · SIGABRT signal 6 — 테스트 바이너리째 내려간다
복원	green — 2 passed

시작 비용 — 수로

제안이 「every start-up」을 비용으로 지목했으므로 잰다. 결정론 계수(하니스 counter · give_up_after=0 = 숨기지 않고 «세기만»):

형상	로더가 java/lang/String 을 묻는 횟수
확인 있음	2
없음	1

추가 1회. 곁의 resolve_class 는 추가가 아니라 «이동» 이다(프로퍼티 루프가 하던 해석이 앞당겨진다).
★벽시계 측정은 버렸다 — 형제 레인이 다른 repo 에서 cargo 를 돌아 같은 형상 p50 이 69ms~1690ms 로 흔들렸고, 교대 8회 중 3회는 «확인 있는 쪽»이 더 빨랐다. 부하를 잰 것이라 수를 주장하지 않는다.

안 한 것

★이 두 클래스만 덮는다 — 두 클래스의 생성자·정적 초기화가 닿는 것은 미측정(티켓 non-goal · 후속 카드로 남겼다).

DoD — 9명령 전건 rc=0

fmt 7s · clippy 431s · +beta clippy 236s · wasm32 clippy 458s · test 1531s · 검사기 4종 0
★전부 콜드 컴파일(캐시 아님) · worklog_json 69파일 0문제(새 쌍 포함)

🤖 Generated with Claude Code