On Fri, 23 Oct 2020 10:25:43 GMT, Erik Österlund <eosterl...@openjdk.org> wrote:
> The escape barrier reallocates scalarized objects potentially deep into the > stack of a remote thread. Each allocation can safepoint, causing referenced > frames to be invalid. Some sprinklings were added that deal with that, but I > believe it was subsequently broken with the integration of the new vector > API, that has its own new deoptimization code that did not know about this. > Not surprisingly, the integration of the new vector API had no idea about > this subtlety, and allocates an object, and then reads an object deep from > the stack of a remote thread (using an escape barrier). I suppose the issue > is that all these 3 things were integrated at almost the same time. The > problematic code sequence is in VectorSupport::allocate_vector() in > vectorSupport.cpp, which is called from Deoptimization::realloc_objects(). It > first allocates an oop (possibly safepointing), and then reads a vector oop > from the stack. This is usually fine, but not through the escape barrier, > with concurrent stack sc anning. While I have not seen any crashes yet, I can see from code inspection, that there is no way that this works correctly. > > In order to make this less fragile for future changes, we should really have > a RAII object that keeps the target thread's stack of the escape barrier, > stable and processed, across safepoints. This patch fixes that. Then it > becomes much easier to reason about its correctness, compared to hoping the > various hooks are applied after each safepoint. > > With this new robustness fix, the thread running the escape barrier, keeps > the target thread stack processed, straight through safepoints on the > requesting thread, making it easy and intuitive to understand why this works > correctly. The RAII object basically just has to cover the code block that > pokes at the remote stack and goes in and out of safepoints, arbitrarily. > Arguably, this escape barrier doesn't need to be blazingly fast, and can > afford keeping stacks sane through its operation. This pull request has now been integrated. Changeset: 5b185585 Author: Erik Österlund <eosterl...@openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/5b185585 Stats: 268 lines in 15 files changed: 164 ins; 72 del; 32 mod 8255243: Reinforce escape barrier interactions with ZGC conc stack processing Co-authored-by: Richard Reingruber <rr...@openjdk.org> Reviewed-by: rrich, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/832
