proposed membar simplification in c2

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Jul 22 09:38:08 PDT 2011


I looked on volatile load in LibraryCallKit::inline_unsafe_access() and the load 
is not passed to MemBarAcquire as we do in Parse::do_get_xxx():

   if (is_volatile) {
     if (!is_store)
       insert_mem_bar(Op_MemBarAcquire);
     else
       insert_mem_bar(Op_MemBarVolatile);
   }

Should we fix it also?

Vladimir

Vladimir Kozlov wrote:
> On 7/22/11 3:10 AM, Roland Westrelin wrote:
>>
>> Hi Vladimir,
>>
>> Thanks for the comments.
>>
>>> In general I like this idea since it is platform independent condition.
>>>
>>> There is code in macro.cpp which look for MemBarAcquire and 
>>> MemBarRelease nodes
>>> to eliminate when eliminating locks and in memnode.cpp for scalar 
>>> replaced
>>> object. And there is code in lcm.cpp which checks it also. I would 
>>> suggest to
>>> add new membar nodes MemBarAcquireLock and MemBarReleaseLock instead 
>>> of using
>>> MemBarCPUOrder.
>>
>> Is this what you have in mind?
>> http://cr.openjdk.java.net/~roland/membar/webrev.02/
> 
> Yes, it is good.
> 
>>
>>> Related note: in .ad file we have to add opposite predicate on a 
>>> second version
>>> of membar mach node, otherwise it will be always selected by DFA 
>>> regardless
>>> predicate value:
>>>
>>> instruct membar_volatile() %{
>>> match(MemBarVolatile);
>>> + predicate(!Matcher::post_store_load_barrier(n));
>>> ins_cost(4*MEMORY_REF_COST);
>>
>> The costs are not the same for membar_volatile (4*MEMORY_REF_COST) and 
>> unnecessary_membar_volatile (0) so that
>> guarantees that unnecessary_membar_volatile is tried first and that 
>> when the predicate fails membar_volatile is chosen,
>> right?
> 
> Yes, you are right.
> 
> Thanks,
> Vladimir
> 
>>
>> Roland.


More information about the hotspot-compiler-dev mailing list