ReflectionLongAdderCounter method access check performance penalty

[qsLI]

ReflectionLongAdderCounter didn't setAccessible as true on Method.
Access check is performed when invoked

[ejona86]

How did you notice this? Is this causing a problem? What JDK are you using?

The slowVerifyAccess() should only occur on the first execution, as it should be cached afterward. And then the JIT probably will impact things further.

I just ran a quick JMH benchmark comparing the reflection as-is with accessing the class natively and there's essentially no difference. I didn't try to run it too scientificly, as reflectAdd runs second so the CPU will be hotter and I wasn't using the performance governor, but there doesn't seem to be any huge performance difference lurking.

package io.grpc.internal;

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.LongAdder;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.TearDown;

/**
 * ReflectionLongAdderCounter benchmark.
 */
@State(Scope.Benchmark)
public class ReflectionLongAdderCounterBenchmark {

  private final LongCounter counter = new ReflectionLongAdderCounter();
  private final LongAdder adder = new LongAdder();

  @Benchmark
  @BenchmarkMode(Mode.AverageTime)
  @OutputTimeUnit(TimeUnit.NANOSECONDS)
  public void reflectAdd() throws Exception {
    counter.add(1);
  }

  @Benchmark
  @BenchmarkMode(Mode.AverageTime)
  @OutputTimeUnit(TimeUnit.NANOSECONDS)
  public void nativeAdd() throws Exception {
    adder.add(1);
  }
}

An old Java 8:

$ gradle -PjmhIncludeSingleClass=ReflectionLongAdderCounter :grpc-core:jmh
# JMH version: 1.36
# VM version: JDK 1.8.0_275, OpenJDK 64-Bit Server VM, 25.275-b01
...
# Warmup: 10 iterations, 1 s each
# Measurement: 10 iterations, 1 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
...
Benchmark                                       Mode  Cnt  Score   Error  Units
ReflectionLongAdderCounterBenchmark.nativeAdd   avgt   10  6.410 ± 0.107  ns/op
ReflectionLongAdderCounterBenchmark.reflectAdd  avgt   10  6.407 ± 0.069  ns/op

Java 11:

# JMH version: 1.36
# VM version: JDK 11.0.29, OpenJDK 64-Bit Server VM, 11.0.29+6-post-Debian-1
...

Benchmark                                       Mode  Cnt  Score   Error  Units
ReflectionLongAdderCounterBenchmark.nativeAdd   avgt   10  6.388 ± 0.065  ns/op
ReflectionLongAdderCounterBenchmark.reflectAdd  avgt   10  6.629 ± 0.408  ns/op

Java 21:

# JMH version: 1.36
# VM version: JDK 21.0.9, OpenJDK 64-Bit Server VM, 21.0.9+10-Debian-1gl0
...
Benchmark                                       Mode  Cnt  Score   Error  Units
ReflectionLongAdderCounterBenchmark.nativeAdd   avgt   10  6.360 ± 0.022  ns/op
ReflectionLongAdderCounterBenchmark.reflectAdd  avgt   10  6.743 ± 0.271  ns/op

[kannanjgithub]

The reflection logic has been in vogue since 2017. In general we don't want to make changes unless there is a problem recognized with the code, which in this case doesn't exist as the mini-benchmark results show also.

[qsLI]

When analyzing the CPU flame graphs of our online application, I discovered the overhead from these reflection calls. Of course, this overhead could also be due to inaccurate sampling caused by skidding. The amount is not very large - it's a relatively minor optimization point. However, JIT cannot completely eliminate the overhead of reflection, even though permission checks have caching (individual). Moreover, the code generated after reflection inflation cannot be fully inlined (too many subclasses, type pollution). Below are some results from my local testing.

package io.grpc.internal;


import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.LongAdder;

import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.Warmup;
import org.openjdk.jmh.profile.AsyncProfiler;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

/**
 * 2025/12/4
 */
@State(Scope.Benchmark)
@Fork(value = 2, jvmArgs = {"-Xms2G", "-Xmx2G", "-Dsun.reflect.inflationThreshold=0"})
@Warmup(iterations = 3, time = 10, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 3, time = 10, timeUnit = TimeUnit.SECONDS)
public class AtomicLongTest {

    private final LongCounter counter = new ReflectionLongAdderCounter();
    private final LongAdder adder = new LongAdder();
    private long i  = 0L;
    private long j = 0L;


    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    public void reflectAdd() throws Exception {
        counter.add(i++);
    }

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    public void nativeAdd() throws Exception {
        adder.add(j++);
    }

    /**
     * Main method to run the benchmarks
     */
    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(AtomicLongTest.class.getSimpleName())
                .addProfiler(AsyncProfiler.class, "libPath=/async-profiler-2.8-macos/build/libasyncProfiler.so;output=flamegraph;event=cpu;dir=/tmp")

                .build();

        new Runner(opt).run();
    }

}

result:

# Run complete. Total time: 00:04:24

REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.

Benchmark                         Mode  Cnt          Score          Error  Units
AtomicLongTest.nativeAdd         thrpt    6  497298276.168 ± 25767675.325  ops/s
AtomicLongTest.nativeAdd:async   thrpt                 NaN                   ---
AtomicLongTest.reflectAdd        thrpt    6  145863886.718 ± 17340010.678  ops/s
AtomicLongTest.reflectAdd:async  thrpt                 NaN                   ---

and cpu flamegraphs

• native

flame-cpu-forward.html

• reflect

flame-cpu-forward.html

[ejona86]

145863886.718 ops/s is 6.8 ns per op. There are two LongCounter increments per RPC in CallTracer. I see another in TransportTracer per-message. Are you suggesting you can notice saving 15 ns per RPC, in the worst case of the JIT unable to optimize? A nanobenchmark isn't really all that trustworthy, but it does tell us that "we probably shouldn't be trying to optimize this."

In general, we'd be much more interested optimizing synchronization bottlenecks, as those can get worse in other circumstances. Which is the point of LongAdder. The nanobenchmark would be faster if we used AtomicInteger, but we're willing to make one case slightly slower to reduce the long tail.

You originally opened this issue talking about the access check cost. In your JMH flame graph, you can see that is small. Now the concern is reflection. You said you noticed the stack in flame graphs of your application. What percentage and count of samples were the reflection and the access check, each?

[qsLI]

145863886.718 ops/s is 6.8 ns per op. There are two LongCounter increments per RPC in CallTracer. I see another in TransportTracer per-message. Are you suggesting you can notice saving 15 ns per RPC, in the worst case of the JIT unable to optimize? A nanobenchmark isn't really all that trustworthy, but it does tell us that "we probably shouldn't be trying to optimize this."145863886.718 ops/s 的速率相当于每次操作耗时 6.8 纳秒。在 CallTracer 中，每个 RPC 调用都会触发两次 LongCounter 递增。我在 TransportTracer 中看到，每个消息还会触发一次。你是说_在 JIT 无法优化的最坏情况下 _，你能注意到每次 RPC 调用节省 15 纳秒吗？纳米基准测试的结果其实不太可靠，但它确实告诉我们“我们可能不应该尝试优化这个”。

In general, we'd be much more interested optimizing synchronization bottlenecks, as those can get worse in other circumstances. Which is the point of LongAdder. The nanobenchmark would be faster if we used AtomicInteger, but we're willing to make one case slightly slower to reduce the long tail.一般来说，我们更感兴趣的是优化同步瓶颈，因为在其他情况下，这些瓶颈可能会变得更严重。这正是 LongAdder 的作用所在。如果我们使用 AtomicInteger，纳米基准测试的速度会更快，但我们愿意牺牲一个用例的速度来减少长尾效应。

You originally opened this issue talking about the access check cost. In your JMH flame graph, you can see that is small. Now the concern is reflection. You said you noticed the stack in flame graphs of your application. What percentage and count of samples were the reflection and the access check, each?您最初提出这个问题时讨论的是访问检查的成本。从您的 JMH 火焰图中可以看出，这个成本很小。现在您关注的是反射。您提到您注意到应用程序火焰图中的堆栈信息。反射和访问检查分别占样本的百分比和数量是多少？

I agree that LongAdder should indeed be used from the perspective of avoiding contention.
However, reflection performance is not very good - from a JIT optimization perspective: direct call > method handle > reflect. The sample count for this method is not high, so optimization may not be necessary.
I only noticed this issue while analyzing reflection calls that exist in the project. Thank you very much for everyone taking the time to discuss this.