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

[Andrew Dinn]

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?

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

Well, if I knew the rationale for your choice I might be able to make a
stab at answering that more precisely. I will, of course, copy your code
for now.

regards,


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