v1.2.0

What's New in v1.2.0

Single-pass restore architecture

The restore operation has been rewritten to use a single-pass JDI local-variable setting strategy. Previously, restore used a two-phase approach (Phase 1: rebuild call stack + set parameters, Phase 2: per-frame localsReady() blocking). The new architecture eliminates Phase 2 entirely.

How it works:

• ALL frames (deepest and non-deepest) now jump to BEFORE_INVOKE in their original code sections during replay
• The deepest frame's invoke is the freeze() call itself — during restore, freeze() detects restore mode via a ThreadLocal flag and blocks on a go-latch
• With every frame in its original code section, all local variables are naturally in scope
• JDI sets ALL locals in ALL frames in a single pass
• When RestoredThread.resume() releases the go-latch, freeze() returns normally and user code continues

Benefits:

• Simpler, more reliable restore — no per-frame Phase 2 synchronization
• Eliminated slot-reuse conflicts — emitLocalVariables() reverted to params-only-wide scope
• Removed dead code: the localsReady() / resumePoint() blocking machinery is no longer used by the restore path

API improvements

• Durable.restore() simple overloads now restore, resume, and join automatically
• Advanced overload returns RestoredThread handle with explicit resume() control
• All JDI work completes before restore() returns — no background threads

Bug fixes

• Fixed VerifyError from slot-reuse in emitLocalDefaults() — now tracks actual store instructions for type inference instead of defaulting untracked slots to Object
• Excluded com/intellij/ from instrumentation (IDE runtime classes)

Test results

• 130 unit tests: all pass (including 3 new slot-reuse verification tests)
• 35 E2E integration tests: all pass