[aarch64-port-dev ] AARCH64: 8064611: Changes to HotSpot shared code

[Andrew Haley]

On 11/12/14 04:24, Vladimir Kozlov wrote:
> On 12/10/14 12:44 PM, Andrew Haley wrote:
>> On 12/10/2014 08:27 PM, David Holmes wrote:
>>> If I had paid more attention to this earlier I would have suggested
>>> reversing the sense of the UseBarriersForVolatile flag
>>> (ElideBarriersForVolatiles?) because it makes it seem like using
>>> barriers for volatiles is experimental - which of course it isn't.
>>
>> OK.
>>
>>> Also this seems C2 specific so shouldn't it be defined in c2_globals.hpp?
>>
>> Sure.  This is the Patch That Never Ends, after all.  :-)
>>
>> Let's see what the other reviewers say, and I'll wrap it all together.
>>
>> Thanks,
>> Andrew.
>>
> 
> I agree with David about reversing flag and putting it into
> c2_globals.hpp. But, please, confirm that you left volatile barriers
> generated by C1 compiler (in c1_LIR_Generator.cpp) as they are - I
> don't see any changes there.

I have left barriers in C1 as they are.

> One thing left is barriers for volatile loads - there is
> inconsistency of code in library_call.cpp and parse3.cpp. We
> discussed it already before.

Right, but as I said to David, those barriers cannot be removed from
volatile loads without destabilizing C2.  The dependencies between the
front end and the innards of C2 are unfortunate, but we are where we
are.  I elide the unnecessary load barrier in the back end, so the
generated code is consistently using load acquire and store release.

> If you want to remove MemBarAcquire for volatile loads then, please,
> also change code in Parse::do_get_xxx() in parse3.cpp.

I can't, because C2 breaks.  Do you think this is a bug, or just a
rather pathological dependency between the front- and middle-ends?

Andrew.