proposed membar simplification in c2

[Tom Rodriguez]

On Jul 22, 2011, at 9:38 AM, Vladimir Kozlov wrote:

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

I don't know if we want to fix it as part of Rolands changes but it does seem that both the MemBarAcquire and MemBarVolatile should be emitted the same as the bytecodes would have emitted them, with a precedence edge.

tom

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