RFR(m): 8220351: Cross-modifying code

[Robbin Ehn]

On 2019-03-11 11:26, Andrew Haley wrote:
> 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?

They are only changed during a GC safepoint on archs with 
mustIterateImmediateOopsInCode set to true, AFAIK.
Arm and aarch64 have it false.

/Robbin

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