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

[Andrew Haley]

On 11/20/2014 03:31 PM, Andrew Dinn wrote:
> On 20/11/14 15:18, Andrew Haley wrote:
>> On 11/20/2014 03:16 PM, Andrew Dinn wrote:
>>> 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
> 
> Hmm, semantics :-)
> 
> Because much as I understand what effect each of them will have --
> in the most narrow sense that it will update the instruction cache
> at that point during execution -- I still don't understand why this
> is an appropriate thing to perform at any of the locations you have
> chosen taken individually. Nor, indeed, why that would be a more or
> less appropriate place to call isb() than any other location. To me
> that's by far the most important aspect of why they are needed (and
> that aspect involves both the correctness/completeness of the
> totality of calls as well as of each individual call).
> 
>>> 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.
> 
> Ok, so that seems to imply that these are the points (and the only
> points) where we might attempt to execute recently modified code. Is
> that the principle behind the choice of locations?

Yes.  As far as I am aware, I have put a maybe_isb() after every call
which could, in theory, have modified code.  This is pretty much every
runtime call because any call might trigger a safepoint, and a
safepoint rewrites inline caches, and we might be about to return to
an inline cache.

maybe_isb() is called for every runtime call and every native call
before returning to the caller.  Beyond that it does not matter where
they are placed, either from a performance or correctness point of
view.

Andrew.