On Fri, 9 Jun 2023 16:53:15 GMT, Andrew Haley <a...@openjdk.org> wrote:
> Move `runWith()` from `VirtualThread` to `BaseVirtualThread`. > > `BoundVirtualThread` does not use `runWith()` to run its task, so when a VM > error occurs it can not recover scoped values. > > Moving `runWith()` into the common subclass of both `VirtualThread` and > `BoundVirtualThread` fixes the problem. One suggestion for the test is to have it re-run with -XX:-VMContinuations on platforms/ports that do do have VM continuations support. Some of the tests for virtual threads do the same thing to ensure this operating mode is tested. This should do it: --- a/test/jdk/java/lang/ScopedValue/StressStackOverflow.java +++ b/test/jdk/java/lang/ScopedValue/StressStackOverflow.java @@ -21,8 +21,8 @@ * questions. */ -/** - * @test +/* + * @test id=default * @summary StressStackOverflow the recovery path for ScopedValue * @enablePreview * @run main/othervm/timeout=300 -XX:-TieredCompilation StressStackOverflow @@ -30,6 +30,13 @@ * @run main/othervm/timeout=300 StressStackOverflow */ +/* + * @test id=no-vmcontinuations + * @requires vm.continuations + * @enablePreview + * @run main/othervm/timeout=300 -XX:+UnlockExperimentalVMOptions -XX:-VMContinuations StressStackOverflow + */ + ------------- PR Comment: https://git.openjdk.org/jdk/pull/14399#issuecomment-1585769878
