RFR: 8221554: aarch64 cross-modifying code

[Robbin Ehn]

On Thu, 15 Oct 2020 11:07:20 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> > A question, ISB don't flush the I-cache which I thought was needed?
> > I would have expected something more similar to gcc clear_cache.
> 
> (Possible I've missed something in your question...)
> Any cache flushing would be performed by the thread that modifies the code.
> The cross_modify_fence is for the other threads after the code has been modified. The only thing they need to do is an
> isb.

Correct me if I'm wrong:
We write the updated instructions to D-cache which is not coherent with the I-cache.
To synchronize the I-cache to what we wrote in the D-cache, we first need make sure the D-cache is committed to memory.
Then each processor must invalidate it's I-cache, thus fetching the new instructions from memory.
So yes the thread that modifies the code should make sure the D-cache is consistent with main memory.
Can the I-cache invalidation be done by the modifying thread in a distributed way ?

When we do "fix_oop_relocations" we end up calling: MacroAssembler::patch_oop(..) in aarch64 case.
To me this indicate that we just changed an oop in a code segment, but I see no signs of above.

Maybe I got something wrong about how this I-cache/D-cache works or missed something in our code?

I think @theRealAph suggested having a indirect to the oops and thus move them of out code and avoiding I-cache.

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

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