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.koz...@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.
>>
>>
