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

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Dec 11 09:38:10 UTC 2014


On 12/11/14 12:54 AM, Andrew Haley wrote:
> 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.

Okay.

>
>> 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?

Most likely bug. If you eliminate barriers in all places where we generate volatile load and stores they should look 
like normal mem ops in Ideal graph - this should work. I can try it tomorrow to see what happens. I assume you mean "C2 
breaks" is crash during compilation. Do you have special test to show that?

Thanks,
Vladimir

>
> Andrew.
>


More information about the aarch64-port-dev mailing list