[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Integrated: 8255243: Reinforce escape barrier interactions with ZGC conc stack processing
From:       Erik =?UTF-8?B?w5ZzdGVybHVuZA==?= <eosterlund () openjdk ! java ! net>
Date:       2020-10-29 14:22:56
Message-ID: waaDM8WUFiFcDd1w3UxZHkD4gtaTVfxZ-fgHnLZbe0Q=.7d0b85cb-d54e-4696-824e-2eb0e6a2e7ce () github ! com
[Download RAW message or body]

On Fri, 23 Oct 2020 10:25:43 GMT, Erik Österlund <eosterlund@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 <eosterlund@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 <rrich@openjdk.org>
Reviewed-by: rrich, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/832


[prev in list] [next in list] [prev in thread] [next in thread]