RFR: 8310239: Add missing cross modifying fence in nmethod entry barriers [v2]

[Erik Österlund]

On Wed, 11 Oct 2023 01:13:59 GMT, Dean Long <dlong at openjdk.org> wrote:

> In particular, I'm wondering about branch prediction. The "beyond reach of the thread's current control flow" to me only rules out pre-fetching code that is truly unreachable (ignoring unconditional branches). What about this scenario:
> 
> 1. Thread 1 reaches 1st instruction of nmethod, and predicts that the entry barrier slow path branch will not be taken, so it loads the some number of instructions past the branch into the pipeline, including instructions with oop immediates.
> 2. Before Thread 1 reaches the entry barrier compare, another thread calls the same nmethod, takes the slow path, patches oops in instructions, and disarms the entry barrier
> 3. Thread 1 sees the disarmed conditional branch and continues to execute the previously fetched pipeline which contains stale oops.

That is precisely what the asynchronous cross modifying code has to take care of, and was explicitly mentioned before revision 3.41. And that's precisely why we don't do like AArch64 where an explicit epoching scheme forces it to synchronous cross modifying code.

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

PR Comment: https://git.openjdk.org/jdk/pull/14543#issuecomment-1772900035