RFR(m): 8220351: Cross-modifying code
Robbin Ehn
robbin.ehn at oracle.com
Tue Mar 19 16:43:45 UTC 2019
Hi all, here is v2:
Full:
http://cr.openjdk.java.net/~rehn/8220351/v2/webrev/
Inc:
http://cr.openjdk.java.net/~rehn/8220351/v2/inc/webrev/
The deprecated non-TLH path is missing the correct cross-mod fence, but since 13
will be the last release containing that code path I think that is okay.
We just leave native/native trans armed, and let the thread disarm on the
transition. If it disarms a new safepoint, we re-arm and stop at next polling
site, that avoids recursion.
Passes stress and hs-t1-5.
As in the previous mail, performance numbers look good.
Thanks, Robbin
On 3/8/19 4:24 PM, Robbin Ehn wrote:
> Hi all, please review.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8220351
> Changeset:
> http://cr.openjdk.java.net/~rehn/8220351/webrev/
>
> After a JavaThread have been in a safepoint/(handshake) safe state it can start
> executing updated code. E.g. an oop in the instruction stream can have been
> updated.
>
> Most hardware's require a barrier or that the code cross modified is far away to
> guarantee that the thread executing the updated instruction stream sees the
> modification.
>
> What far away is and how far an update instruction stream is from a safepoint
> safe state is not clear.
>
> To be compliant with those architectures an instruction stream barrier must be
> added when leaving the safepoint safe state.
>
> There may be crashes today due to this missing barrier.
> A new CPU with deeper pipeline or changes to the VM which moves a safepoint safe
> state closer to a nmethod can increase changes of a crash.
>
> A few benchmarks will see a performance regression with the extra serializing,
> such as Octane-Crypto -5% (x86).
>
> With a much more elaborate fix, such as changing the local poll to have more
> than two states (armed/disarmed), it would be possible to only emit such
> instruction stream barrier when the poll have been armed while the thread was
> safepoint safe.
>
> Passes t1-3 on our platforms, and test built what I can.
>
> Thanks, Robbin
More information about the hotspot-dev
mailing list