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

[Andrew Haley]

On 11/20/2014 03:16 PM, Andrew Dinn wrote:
> On 20/11/14 15:02, Andrew Haley wrote:
>> On 11/20/2014 02:31 PM, Andrew Dinn wrote:
>>> 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.
> 
> Yes, I realise why we need barriers on both sides of a code memory
> update (what is written in data cache by any given thread must be
> updated in instruction cache by all executing threads).

So why did you say

> I don't understand why
> these calls are needed in /any/ case

> What I did not understand was why the isb instructions were located at
> the indicated lines in the check-in. Why those lines? Why not others?

It does not matter as long as they are executed before any modified
code.

> I ask because it may be that jdk7 does not require exactly the same
> calls (more, less or different).

Maybe.

Andrew.