On Fri, 26 Sep 2025 22:13:00 GMT, Chen Liang <[email protected]> wrote:
> Hotspot profiles by bytecode; as a result, some shared methods become > polluted and suffer in type profiling, as described in depth in [this > essay](https://cr.openjdk.org/~jrose/jvm/equals-profile.html) by John Rose. > The record methods generated by `ObjectMethods::bootstrap` just proved itself > another victim in this RFE. > > To bypass this issue, I naively generated distinct bytecode to allow distinct > profiles for now. If hotspot adds any kind of split profiles exposed via > internal APIs, we can migrate to such split profile and throw away these > extra copies of bytecode. > > In particular, in a method handle tree, each leaf method handle seems not > separately profiled - for example, all DMH to Object.hashCode share the same > profile regardless of their position in a MH tree, making MH trees less > useful than explicitly rolled bytecode, unfortunately. > > The attached benchmark should be a good demonstration of the effect of type > profiling. Initial benchmark results: Benchmark Mode Cnt Score Error Units RecordMethodsBenchmark.equalsDistinct thrpt 15 413.727 ± 5.317 ops/us RecordMethodsBenchmark.equalsGenerated thrpt 15 410.474 ± 6.298 ops/us RecordMethodsBenchmark.equalsPolluted thrpt 15 185.471 ± 3.800 ops/us RecordMethodsBenchmark.hashCodeDistinct thrpt 15 1190.923 ± 21.937 ops/us RecordMethodsBenchmark.hashCodeGenerated thrpt 15 1201.802 ± 20.521 ops/us RecordMethodsBenchmark.hashCodePolluted thrpt 15 239.675 ± 3.195 ops/us Shows the generated method bodies benefit from type profiling. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27533#issuecomment-3340658520
