RFR(m): 8220351: Cross-modifying code

[David Holmes]

Hi Robbin,

Sorry but I find it hard to understand how we suddenly need to sprinkle 
instruction stream synchronization operations all around the VM. I can't 
even see how some of these locations relate to "code modification". Can 
you please explain in more detail exactly what the problem is.

Thanks,
David

On 9/03/2019 1:24 am, 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