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

[David Holmes]

On 11/12/2014 12:50 AM, Andrew Haley wrote:
> On 12/10/2014 12:12 PM, Andrew Haley wrote:
>> On 12/10/2014 11:34 AM, David Holmes wrote:
>>> On 10/12/2014 8:59 PM, Andrew Haley wrote:
>>>> http://cr.openjdk.java.net/~aph/aarch64-8064611-5/
>>>
>>> src/share/vm/opto/memnode.hpp
>>>
>>> Won't the unconditional return for aarch64 cause unreachable code warnings?
>>
>> Not for me, but I can add an else if you like.
>>
>>> src/share/vm/opto/parse3.cpp
>>> src/share/vm/opto/library_call.cpp
>>>
>>> I'm not a C2 person but it seems strange to me that in one place if not
>>> using barriers for volatile you do nothing; whereas in the other place
>>> you insert Op_MemBarCPUOrder ??
>>>
>>> src/share/vm/runtime/globals.hpp
>>
>> That's a fair comment.  Unfortunately C2 breaks if there are only CPU
>> barriers here, so I have to elide them in the back end.  It is very
>> unfortunate, but there are many places where C2 makes assumptions
>> about the ideal graphs generated by the front end.
>>
>>> Shouldn't UseBarriersForVolatile only be false on aarch64 ??
>>
>> Oh gosh, however did I miss that?  <red face>
>
> Fixed thusly:
>
> http://cr.openjdk.java.net/~aph/aarch64-8064611-7/

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.

Also this seems C2 specific so shouldn't it be defined in c2_globals.hpp?

Thanks,
David

> Thanks,
> Andrew.
>