RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

Vitaly Davidovich vitalyd at gmail.com
Tue Feb 17 19:21:13 UTC 2015


IMO I don't think such barriers should be removed just because EA is able
to elide the heap allocation.

On Tue, Feb 17, 2015 at 2:15 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
> wrote:

> There was discussion should we remove such barriers or not because they
> create memory operations ordering which could be different if we remove
> them.
>
> To eliminate them we need to add 'precedent' edge to store's membar as we
> do, for example, for loads:
>
>   if (field->is_volatile()) {
>     // Memory barrier includes bogus read of value to force load BEFORE
> membar
>     insert_mem_bar(Op_MemBarAcquire, ld);
>   }
>
> MemBarNode::Ideal() will do elimination.
>
> Regards,
> Vladimir
>
>
> On 2/17/15 10:58 AM, Andrew Haley wrote:
>
>> On 02/17/2015 06:42 PM, John Rose wrote:
>>
>>> The remaining store fence is probably a bug.  A store fence for
>>> scalarized (lifted-out-of-memory) final fields should go away, since the
>>> fields are not actually stored in heap memory.
>>>
>>
>> After inlining how would escape analysis know that the store fence is
>> associated with final fields rather than, say, an explicit
>> Unsafe.storeFence() ?
>>
>> Andrew.
>>
>>



More information about the core-libs-dev mailing list