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

[Andrew Dinn]

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

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?

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

regards,


Andrew Dinn
-----------