proposed membar simplification in c2

[Vladimir Kozlov]

Roland,

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.

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);

Vladimir

Roland Westrelin wrote:
> To implement the java memory model, on a monitor operation, c2 currently 
> adds a MemBarAcquire/MemBarRelease node after/before the monitor 
> enter/exit. No membar instruction is emitted for these 
> MemBarAcquire/MemBarRelease: in the ad file, 
> Matcher::prior_fast_lock()/Matcher::post_fast_unlock() is used to detect 
> a MemBarAcquire/MemBarRelease associated with a monitor enter/exit and 
> to use an empty encoding.
> 
> Matcher::post_fast_unlock() is broken with UseOptoBiasInlining: it never 
> returns true.
> 
> Rather than fix it, I suggest we use MemBarCPUOrder nodes instead of 
> MemBarAcquire/MemBarRelease nodes on the monitor enter/exit code paths. 
> That would have the same effect as MemBarAcquire/MemBarRelease with 
> empty encodings and is straightforward.
> 
> http://cr.openjdk.java.net/~roland/membar/webrev/
> 
> Roland.