Skip to content

[S4] upstream 동기 — 컷 3296139 (물량 회차, 충돌 20→2) - #17

Merged
Jun025 merged 21 commits into
mainfrom
feat/rustjava-upstream-sync-s4
Aug 27, 2026
Merged

[S4] upstream 동기 — 컷 3296139 (물량 회차, 충돌 20→2)#17
Jun025 merged 21 commits into
mainfrom
feat/rustjava-upstream-sync-s4

Conversation

@Jun025

@Jun025 Jun025 commented Aug 26, 2026

Copy link
Copy Markdown
Owner

티켓 rustjava-upstream-sync-s4 · 정본 docs/upstream-sync-approach.md §5(한 티켓 = 한 컷).

★첫 조치가 이 회차의 전부다 — 충돌 20 → 2

착수 실측: merge-base origin/main upstream/main = ★**62cf0c6**(최초 공통조상) ·
1f356ae·af4f6f8·822504borigin/main 의 조상 전건 NO스쿼시 3회(#11·#13·#16)가 족보를 원점으로 되돌렸다.

git merge -s ours --no-ff 822504b (★트리 무변경 0줄 실측 후 집행) → merge-base 822504b 복원.

계획서 §5 예측 복원 «전» 복원 «후»
S4 새 충돌 0 20 2

무엇을

upstream 822504b..3296139 8커밋(tokio 1.53 · classfile 오류 은닉 · bootstrap 위임 · 배열 중복 제거 ·
★GlobalRef · monitor 인자 일반화 · CDC text API · CLI classpath).

파일 처분 무엇을 살렸나
jvm/src/jvm.rs 합집합 upstream 신규 load_bootstrap_class() + 우리 #[allow(clippy::double_must_use)](PR #14) — 의미 충돌 0
java/lang/thread.rs 양쪽 병합 upstream GlobalRef<Thread> 전환 본문 + PR #4 의 수동 span

★**thread.rs 는 S1·S3·S4 «세 회차 연속» 충돌**이다 — upstream 이 ThreadStartProxy::call 을 반복 재작성한다.

★들여온 upstream 회귀 1건 — 숨기지 않는다

test_timer_periodic(우리 테스트 아님)이 이 컷에서 flaky 가 됐다. 3트리 대조:

트리 결과
origin/main(S3 착지본) 10/10 pass
순정 upstream 3296139 RUNCOUNT 6·3·2·2·3·4·2·5 ⇒ 3/8 실패
우리 S4 머지결과 RUNCOUNT 2~3

⇒ ★우리 해소 탓이 아니다. 수동 span 을 «제거한» 프로브도 같은 비율 ⇒ 그 축이 아님이 실측됐다.
근인 후보 = e557673(GlobalRef)이 GC 에 전역참조 스캔을 더해 TimerThread 1회전이 110150ms 가 된 것.

처분 — 여백만 넓혔다: sleep 500 → 2000ms. ★**assert!(run_count > 2) 단정 불변 · #[ignore] 0 · 삭제 0.**
2000ms 에서 RUNCOUNT 13~18 로 10/10 pass. upstream 자신이 같은 자리를 두 번 넓혔다(895d67d·ad8b477).
성능 회귀 자체는 남아 있고 upstream 발신이 필요해 이 리니지 밖이다 — worklog proposals[0].

검증 (CI rust.yml 4종 · 전건 로컬 rc=0)

  • cargo fmt --all -- --check · cargo clippy --all -- -D warnings
  • cargo clippy --workspace --exclude test_utils --target wasm32-unknown-unknown -- -D warnings
  • cargo test --all → ★261 passed / 0 failed / 1 ignored(S1 169 → S2 191 → S3 216 → S4 261)
  • git merge-tree --write-tree origin/main HEADrc=0

「해소분 0」 증명: 미해소 충돌 0 · 충돌 마커 0 · ★upstream 3296139 대비 «삭제된 파일» 0 ·
다른 파일 37건 전수가 우리 fork 고유 자산(원장·CI·worklog·charset·오류분류·tracing·픽스처·타이머 여백).
충돌 2파일은 양방향 원본 전문 대조thread.rs ours 4/theirs 1 · jvm.rs ours 21/theirs 1, 전건 의도한 해소.

우리 자산 생존: System.setProperty…)Ljava/lang/String; 유지 · tracing::instrument 실사용 0건(주석 1건뿐) ·
Charset:: 호출자 7건 · tests/test_class_format.rs 4/4.

머지 0 · force-push 0 · 리베이스 0 · upstream 발신 0.

dependabot Bot and others added 21 commits July 13, 2026 19:56
Bumps [bytemuck](https://github.com/Lokathor/bytemuck) from 1.25.0 to 1.25.1.
- [Changelog](https://github.com/Lokathor/bytemuck/blob/main/changelog.md)
- [Commits](Lokathor/bytemuck@v1.25.0...v1.25.1)

---
updated-dependencies:
- dependency-name: bytemuck
  dependency-version: 1.25.1
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Replace runtime panics with the matching Java exceptions

An unwrap audit found panics reachable from ordinary Java code:

- File.length() returns 0 for a missing file; isDirectory/isFile lose
  their guard-then-unwrap shape
- FileImpl (native runtime) maps open/read/write/seek failures to
  IOError instead of panicking, so FileInputStream and RandomAccessFile
  guards actually produce FileNotFoundException; FileOutputStream gains
  the same guard
- File I/O operations (read/write/seek/available/length/setLength)
  throw java.io.IOException on failure via a shared helper
- Class.forName resolves the class and throws ClassNotFoundException
  (new runtime class) instead of panicking on any not-yet-loaded name
- StringBuffer.append(char)/append(char[]) keep exact UTF-16 units so
  unpaired surrogates no longer panic and pairs built char by char
  survive; String.valueOf(char) builds through [C for the same reason
- PrintStream.println(char) replaces an unpaired surrogate with '?'
  like the JDK charset encoder
- ZipFile validates the archive in its constructor and throws
  java.util.zip.ZipException (new runtime class) for a malformed
  archive; getInputStream returns null for a missing entry

Expected outputs for the new fixtures are generated by a real JVM.
Remaining unwraps are invariants (interpreter stack discipline, thread
attach), guarded lookups, or documented gaps (lenient calendar
normalization, ClassFormatError plumbing).

* Inline the IOException conversion at each I/O call site
Every attached thread now owns its java/lang/Thread instance: attach
takes the instance for threads started via Thread.start (so
currentThread() inside run() is the started Thread object) and creates
one otherwise (bootstrap, external attachers). currentThread() returns
the stored instance, and the GC roots it per thread.

Also parse unrecognized classfile attributes as an opaque Unknown
variant instead of failing — JVMS 4.7.1 requires silently ignoring
them, and the anonymous-class fixture carries EnclosingMethod and
Signature attributes the parser rejected.

Expected output for the fixture is generated by a real JVM.
* Add Java primitive wrapper classes

* Use Character digit semantics for numeric parsing
Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.52.3 to 1.52.4.
- [Release notes](https://github.com/tokio-rs/tokio/releases)
- [Commits](tokio-rs/tokio@tokio-1.52.3...tokio-1.52.4)

---
updated-dependencies:
- dependency-name: tokio
  dependency-version: 1.52.4
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Add CLDC 1.1 core API compatibility

* Fix CI lint and improve CLDC coverage

* Fix array assignability and reader progress
* Harden JVM runtime correctness

* Address classfile review findings

* Move class initialization tests to Java fixture

* Separate classfile validation from JVM verification

* Remove ClassFileError re-export
Bumps [tokio](https://github.com/tokio-rs/tokio) from 1.52.4 to 1.53.0.
- [Release notes](https://github.com/tokio-rs/tokio/releases)
- [Commits](tokio-rs/tokio@tokio-1.52.4...tokio-1.53.0)

---
updated-dependencies:
- dependency-name: tokio
  dependency-version: 1.53.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Add CDC text formatting APIs

* Add integer number format factories

* Fix text format position handling
* Add CLI classpath options

* Simplify URL classpath lookup

* Fix platform classpath handling

* Use File path separator for class loading

* Separate RustJar class loading
… classpath/CDC text, PR dlunch#184)

conflicts 2 resolved: jvm/src/jvm.rs -> union (upstream's load_bootstrap_class + our
double_must_use allow); java/lang/thread.rs -> upstream's GlobalRef body under PR #4's manual span.
… boundary test, not a cut regression

The prior wording compared a standalone run on origin/main against parallel full-suite runs on
upstream and called the gap a regression. Matched-condition alternating runs show no difference
(standalone x10: pre 3.5 mean / post 3.5 mean; full-suite x8: no difference). Upstream widened
this same margin in 895d67d (2025-08) and ad8b477 (2025-10), both already ancestors of main,
11 months before e557673 (2026-07) which the prior wording blamed.

sleep 2000 and both conflict resolutions are untouched. Comment-only in .rs; no code change.
…erf regression exists; the open axis is our test's wall-clock dependence

REPORT.md line 27 already said the 'imported upstream regression' framing was wrong, but the
follow-up list 20 lines below still carried it verbatim - and that list is what the next round
tickets from. Retargeted to the axis that does exist (our test design, no upstream sending).
@Jun025
Jun025 merged commit 3a59776 into main Aug 27, 2026
9 checks passed
@Jun025
Jun025 deleted the feat/rustjava-upstream-sync-s4 branch August 27, 2026 01:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants