[aarch64-port-dev ] RFR(S): 8087341: C2 doesn't optimize redundant memory operations with G1

Roland Westrelin roland.westrelin at oracle.com
Fri Feb 19 07:54:26 UTC 2016


Thanks for the review, Vladimir.

Roland.

> On Feb 15, 2016, at 6:33 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Good. Thank you.
> 
> Vladimir
> 
> On 2/15/16 1:21 AM, Roland Westrelin wrote:
>> 
>>> Can you create new webrev which includes everything (aarch64)?
>> 
>> Here it is:
>> http://cr.openjdk.java.net/~roland/8087341/webrev.01/
>> 
>> Roland.
>> 
>>> And I am satisfied with your answers to my objections.
>>> 
>>> Thanks,
>>> Vladimir
>>> 
>>> On 2/12/16 4:36 AM, Roland Westrelin wrote:
>>>> Hi Andrew,
>>>> 
>>>>> A patch for the AArch64 C2 volatile/CAS generation code which deals with
>>>>> the effects of your proposed C2 patch is available as a webrev
>>>>> 
>>>>> http://cr.openjdk.java.net/~adinn/8087341-aarch64/webrev.00/
>>>> 
>>>> Thanks for putting that together. I didn’t expect that simple change to cause so much trouble.
>>>> 
>>>>> n.b. I have /not/ created a separate issue for the AArch64 part of this
>>>>> fix. I am not sure whether you want to combine it with your patch or
>>>>> push it as a separate stage.
>>>> 
>>>> I can push everything together and list you as a contributor (in the contributed-by field) if that works for you.
>>>> 
>>>> Vladimir, can you take another look at this? Your two objections were:
>>>> 
>>>>> Also we have specialized insert_mem_bar_volatile() if we don't want wide memory affect. Why not use it?
>>>> 
>>>> The membar in the change takes the entire memory state as input but only changes raw memory. I don’t think that can be achieved with insert_mem_bar_volatile(). As explained by Mikael, the membar is here to force ordering between the oop store and the card table load. That’s why I think the membar’s inputs and outputs should be set up that way.
>>>> 
>>>>> And we need to keep precedent edge link to oop store in case EA eliminates related allocation.
>>>> 
>>>> Mikael said it’s not ok to eliminate the memory barrier if we leave the gc barrier.
>>>> 
>>>> Roland.
>>>> 
>> 



More information about the aarch64-port-dev mailing list