Lock coarsening LogCompilation output?

[Vladimir Ivanov]

Chris,

Second eliminate_lock corresponds to unlock operation (lock='0'), which 
should be also eliminated (corresponding diagnostic logic in 9 [1]).

VM doesn't attach JVM state to the unlock node in the product binaries 
(see as_Unlock()->dbg_jvms()), but it is present in fastdebug/slowdebug 
binaries [2].

Not sure why the state is pruned in product. Probably, there are some 
performance after-effects from keeping the state for unlock node.

Best regards,
Vladimir Ivanov

[1] 
http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/0d3c20ac648e/src/share/vm/opto/callnode.cpp#l1886

[2] latest hs-comp 9 fastdebug build:
<eliminate_lock lock='1' compile_id='10' class_id='lock' 
kind='coarsened' stamp='1.071'>
   <jvms bci='61' method='844'/>
</eliminate_lock>
<eliminate_lock lock='0' compile_id='10' class_id='unlock' 
kind='coarsened' stamp='1.071'>
   <jvms bci='64' method='844'/>
</eliminate_lock>

On 7/22/15 5:04 PM, Chris Newland wrote:
> Hi,
>
> I'm building support into JITWatch for highlighting eliminated heap
> allocations and locks (either via elision or coarsening) and I'm confused
> by the LogCompilation output in this case:
>
> Given the source code here:
> https://github.com/AdoptOpenJDK/jitwatch/blob/master/src/main/resources/examples/LockCoarsen.java
>
> Which consists of two synchronized(this) regions separated by a single
> statement modifying a local primitive.
>
> I get the following LogCompilation output:
> https://gist.github.com/chriswhocodes/124984ce8078290485e7
>
> Which has the following elimination info in the optimizer phase:
>
> <eliminate_lock lock='1'>
> <jvms bci='61' method='818'/>
> </eliminate_lock>
> <eliminate_lock lock='0'>
> </eliminate_lock>
>
> BCI 61 refers to the 2nd synchronized block's monitor enter which I
> believe will be eliminated due to coarsening but I don't understand what
> the
>
> <eliminate_lock lock='0'>
> </eliminate_lock>
>
> tag means, and why it doesn't contain a jvms tag?
>
> Does it mean the first synchronized block has also been eliminated (via
> elision) ? I don't see any "lock cmpxchg" related to the first
> synchronized block in the PrintAssembly?
>
> Thanks,
>
> Chris
>
>
>
>