RFR(m): 8220351: Cross-modifying code

[Andrew Haley]

On 3/8/19 3:24 PM, Robbin Ehn wrote:

> 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.

Hmm, interesting. I think it works on on AArch64 at present because
the segfault trap we take is effectively a full synchronization
operation.

An AArch64 ISB (instruction synchronization barrier) invalidates the
pipeline. It doesn't invalidate the instruction cache, which we'd need
to do to see a relocated OOP. If an instruction is modified by some
other thread we need to flush the local icache, but to do that we need
to know which instructions have been changed. We could create a
modification queue, but that seems rather elaborate.

What is is that changes OOPs in the instructions during a handshake?
Is it just garbage collection, or does it happen at other times too?

We could simply move OOPs (and class metadata pointers?) into the
constant pool. That would have some performance impact on in-order
CPUs, but hopefully not much on out-of-order ones.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671