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. This pull request has now been integrated. Changeset: 43e036ba Author: Chen Liang <[email protected]> URL: https://git.openjdk.org/jdk/commit/43e036ba89dc8a09129313705f61354463d2c266 Stats: 367 lines in 2 files changed: 317 ins; 18 del; 32 mod 8366424: Missing type profiling in generated Record Object methods Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/27533
