8253063: ScopedAccessError is sometimes thrown spuriously #323
After running the test for shared segment handshake during unrelated work, I noted that the test exhibit two kind of failure modes:
After some investigation carried out by @fisk, turns out that (2) was caused by the fact that when we exit from deoptimization we don't check for pending async exception (while we check for regulart ones). This condition was not triggered in other tests because, it seems, plain unsafe accesses are effectively atomic once intrinisfied - e.g. there can be no safepoint between check and access. But the vectorized mismatch routine is a biggie Java routine which gets some initial compilation (by C1) - and this is when the bug hit.
The problem (2) was more difficult to pinpoint - basically, there are some routines in the VM which are hostile w.r.t. async exceptions - and are marked with the special
With these fixes, the test passes and no more spurious failures can be observed (I left it running for a long time ;-)).
After integration, the commit message will be:
Since the source branch of this PR was last updated there have been 62 commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid automatic rebasing, please merge
@mcimadamore Since your change was applied there have been 62 commits pushed to the
Your commit was automatically rebased without conflicts.
Pushed as commit 1cc7a78.