LinuxPerfAsmProfiler 显示 Java 8 的 Java 代码对应的程序集热点，但不适用于 Java 14

Posted 2023-03-06

【中文标题】LinuxPerfAsmProfiler 显示 Java 8 的 Java 代码对应的程序集热点，但不适用于 Java 14

【英文标题】：LinuxPerfAsmProfiler shows Java code corresponding assembly hot spot for Java 8, but not for Java 14

【发布时间】：2020-08-13 14:52:22

【问题描述】：

在调查与 Spring 的 org.springframework.util.ConcurrentReferenceHashMap（截至 spring-core-5.1.3.RELEASE）的实例化相关的问题时，我使用了与 JMH 一起提供的 LinuxPerfAsmProfiler 来分析生成的程序集。

我只是运行这个

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

在 JDK 8 上进行基准测试可以识别不明显的热点之一：

  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

这对应于将默认值不必要地分配给易失性字段：

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

而Segment 又在CCRHM 的构造函数中循环实例化：

public ConcurrentReferenceHashMap(
    int initialCapacity, float loadFactor, int concurrencyLevel, ReferenceType referenceType) 
  this.loadFactor = loadFactor;
  this.shift = calculateShift(concurrencyLevel, MAXIMUM_CONCURRENCY_LEVEL);
  int size = 1 << this.shift;
  this.referenceType = referenceType;
  int roundedUpSegmentCapacity = (int) ((initialCapacity + size - 1L) / size);
  this.segments = (Segment[]) Array.newInstance(Segment.class, size);
  for (int i = 0; i < this.segments.length; i++) 
   this.segments[i] = new Segment(roundedUpSegmentCapacity);
  

所以指令很可能真的很热。组件的完整布局可以在我的gist

中找到

然后我在 JDK 14 上运行相同的基准测试并再次使用 LinuxPerfAsmProfiler，但现在我没有明确指向 volatile int count = 0 in captured assembly。

寻找lock addl $0x0 指令，它是0 在lock 前缀下的分配我发现了这个：

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

很可能对应volatile int count = 0，因为它遵循Segment的超类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

问题是我在生成的程序集中根本没有提到putfield count。

谁能解释我为什么看不到它？

【问题讨论】：

确实，看起来一些 JIT 优化破坏了编译代码和 bci 之间的映射。如果使用-XX:MaxInlineLevel=0 运行JDK 14，“putfield count”注释将再次可见。

@apangin 谢谢！然后我应该将其报告给hotspot-compiler-dev 或jmh-dev 邮件列表吗？你怎么看？

这当然不是 jmh 的错误。 -XX:+PrintAssembly 中缺少调试信息。所以，hotspot-compiler-dev 会更合适。

@apangin 看起来这不会被修复：mail.openjdk.java.net/pipermail/hotspot-compiler-dev/…

是的，很期待。我不能同意这个理由。虽然通常很难维护映射，但这并不意味着在特定情况下绝对不可能。忽略此类问题，甚至没有进行最少的调查，最终将导致根本没有调试信息。

【参考方案1】：

事实证明，您无法使用为例如构建的 hsdis。 JDK 8 与 JDK 11。为了完美匹配，您需要从 JDK 源构建 hsdis，然后构建 JDK 本身并在此 ad-hoc 构建上运行应用程序。

当我调查Missing bounds checking elimination in String constructor? 时，这种方法非常适合我。