The bug here is a thinko in `ScopedValue.scopedValueBindings()`. If the JVM runs out of resources, we throw a `VirtualMachineError`. Running out of resources can happen at almost any time, and can happen while `ScopedValue`'s internal structures are being modified, leaving them in an inconsistent state. We detect when a `VirtualMachineError` happens and walk the stack to find the most-recent set of `ScopedValue` bindings.
When we crate a new `Thread`, we push a sentinel frame onto the stack that we can find in the case that we threw a `VirtualMachineError`. Threads created by the native invocation interface (rather than by Java threads) don't have that sentinel, so a search for it returns null. Therefore, in the rare cases where we have to do a stack walk, we must check for both `NEW_THREAD_BINDINGS` (the sentinel) and `null`. We weren't doing that, we were only checking for null. ------------- Commit messages: - JDK-8319120: Unbound ScopedValue.get() throws the wrong exception Changes: https://git.openjdk.org/jdk/pull/16422/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16422&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8319120 Stats: 43 lines in 2 files changed: 38 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16422.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16422/head:pull/16422 PR: https://git.openjdk.org/jdk/pull/16422
