[aarch64-port-dev ] Query regarding maybe_isb() introduced into jdk8

[Andrew Haley]

On 11/20/2014 02:31 PM, Andrew Dinn wrote:
> I am looking at the following jdk8 aarch64 changeset:
> 
> Changeset: 7220
> Branch: default
> User: aph
> Date: Mon Sep 01 18:10:18 BST 2014
> 
> This introduces a load of isb() calls into various bits of generated
> code via a new assembler method maybe_isb(). I don't understand why
> these calls are needed in /any/ case (never mind in all). Especially
> mysterious are the likes of
> 
>    __ reset_last_Java_frame(false, true);
> 
> +  __ maybe_isb();
> +
> 
> which happens at line 2813 of sharedRuntime_)aarch64.cpp
> 
> How does setting fields in the thread anchor to NULL impose the need to
> update the instruction cache?

Huh?

> Can anyone explain this code?

Yes.  After a code cache flush makes changed instructions observable,
each PE must issue an ISB before executing those instructions.
Otherwise, you fall into the "concurrent modification and execution of
instructions" undefined behaviour.

Instructions can be changed at a safepoint.  We could conditionally
execute an ISB if a safepoint had actually occurred, but an ISB is not
expensive enough to be worth the trouble.

Andrew.