AARCH64: 8064611: Changes to HotSpot shared code
david.holmes at oracle.com
Wed Dec 10 20:27:47 UTC 2014
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:
>>> Won't the unconditional return for aarch64 cause unreachable code warnings?
>> Not for me, but I can add an else if you like.
>>> 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 ??
>> 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:
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?
More information about the hotspot-dev