RFR: 8366424: Missing type profiling in generated Record Object methods
Chen Liang
liach at openjdk.org
Fri Sep 26 22:18:33 UTC 2025
On Fri, 26 Sep 2025 22:13:00 GMT, Chen Liang <liach at openjdk.org> 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
More information about the core-libs-dev
mailing list