JIT optimization broke mapping between compiled code and byte-code instructions on JDK 14 / 15EAP

[Сергей Цыпанов]

Hello,

while investigating an issue related to instantiation of Spring's 
`org.springframework.util.ConcurrentReferenceHashMap` (as of `spring-core-5.1.3.RELEASE`) 
I've used `LinuxPerfAsmProfiler` shipped along with JMH to profile generated assembly.

I simply run this

@Benchmark
public Object measureInit() {
  return new ConcurrentReferenceHashMap<>();
}

Benchmarking on JDK 8 allows to identify one of hot spots (full assembly layout can be found in [1]):

  0.61%        0x00007f32d92772ea: lock addl $0x0,(%rsp)     ;*putfield count
                                                             ; - org.springframework.util.ConcurrentReferenceHashMap$Segment::<init>@11 (line 476)
                                                             ; - org.springframework.util.ConcurrentReferenceHashMap::<init>@141 (line 184)
 15.81%        0x00007f32d92772ef: mov    0x60(%r15),%rdx

This corresponds unnecessary assignment of default value to a volatile field:

protected final class Segment extends ReentrantLock {
  private volatile int count = 0;
}

Then I run the same benchmark on JDK 14 and again use `LinuxPerfAsmProfiler`, 
but now I don't have any explicit pointing to `volatile int count = 0` in captured assembly [2].

Looking for `lock addl $0x0` instuction which is assignment of `0` under `lock` prefix I have found this:

  0.08%                          │  0x00007f3717d46187:   lock addl $0x0,-0x40(%rsp)
 23.74%                          │  0x00007f3717d4618d:   mov    0x120(%r15),%rbx

which is likely to correspond `volatile int count = 0` because it follows the construction of `Segment`'s superclass `ReentrantLock`:

  0.77%                          │  0x00007f3717d46140:   movq   $0x0,0x18(%rax)              ;*new {reexecute=0 rethrow=0 return_oop=0}
                                 │                                                            ; - java.util.concurrent.locks.ReentrantLock::<init>@5 (line 294)
                                 │                                                            ; - org.springframework.util.ConcurrentReferenceHashMap$Segment::<init>@6 (line 484)
                                 │                                                            ; - org.springframework.util.ConcurrentReferenceHashMap::<init>@141 (line 184)
  0.06%                          │  0x00007f3717d46148:   mov    %r8,%rcx
  0.05%                          │  0x00007f3717d4614b:   mov    %rax,%rbx
  0.03%                          │  0x00007f3717d4614e:   shr    $0x3,%rbx
  0.74%                          │  0x00007f3717d46152:   mov    %ebx,0xc(%r8)
  0.06%                          │  0x00007f3717d46156:   mov    %rax,%rbx
  0.05%                          │  0x00007f3717d46159:   xor    %rcx,%rbx
  0.02%                          │  0x00007f3717d4615c:   shr    $0x14,%rbx
  0.72%                          │  0x00007f3717d46160:   test   %rbx,%rbx
                             ╭   │  0x00007f3717d46163:   je     0x00007f3717d4617f
                             │   │  0x00007f3717d46165:   shr    $0x9,%rcx
                             │   │  0x00007f3717d46169:   movabs $0x7f370a872000,%rdi
                             │   │  0x00007f3717d46173:   add    %rcx,%rdi
                             │   │  0x00007f3717d46176:   cmpb   $0x8,(%rdi)
  0.00%                      │   │  0x00007f3717d46179:   jne    0x00007f3717d46509
  0.04%                      ↘   │  0x00007f3717d4617f:   movl   $0x0,0x14(%r8)
  0.08%                          │  0x00007f3717d46187:   lock addl $0x0,-0x40(%rsp)
 23.74%                          │  0x00007f3717d4618d:   mov    0x120(%r15),%rbx

The problem is that I don't have any mention of `putfield count` in generated assembly at all.

I've asked the question on StackOverflow [4] and Andrey Pangin suggests in his comment [5]
that this might be due to broken mapping between compiled code and byte-code causing
miss of debug info in the output of -XX:+PrintAssembly

P.S. The issue is reproducible on JDK 15 built locally, see [3]


  [1]: https://gist.github.com/stsypanov/ff5678987c6f95a2aaf292fa2a3b92a8
  [2]: https://gist.github.com/stsypanov/2e4bd73c39d7465cbdd75ba26d4bc217
  [3]: https://gist.github.com/stsypanov/30fc0f688e6d37612ca017b59ab3e631
  [4]: https://stackoverflow.com/questions/63397711/linuxperfasmprofiler-shows-java-code-corresponding-assembly-hot-spot-for-java-8
  [5]: https://stackoverflow.com/questions/63397711/linuxperfasmprofiler-shows-java-code-corresponding-assembly-hot-spot-for-java-8#comment112109002_63397711