proposed membar simplification in c2 (original) (raw)

Tom Rodriguez tom.rodriguez at oracle.com
Fri Jul 22 15:20:34 PDT 2011

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

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

if (isvolatile) { if (!isstore) insertmembar(OpMemBarAcquire); else insertmembar(OpMemBarVolatile); } 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 membarvolatile() %{ match(MemBarVolatile); + predicate(!Matcher::poststoreloadbarrier(n)); inscost(4*MEMORYREFCOST); The costs are not the same for membarvolatile (4*MEMORYREFCOST) and unnecessarymembarvolatile (0) so that guarantees that unnecessarymembarvolatile is tried first and that when the predicate fails membarvolatile is chosen, right? Yes, you are right. Thanks, Vladimir Roland.

More information about the hotspot-compiler-dev mailing list