On Mon, 20 Oct 2025 21:09:45 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. > > Chen Liang has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains seven additional commits since > the last revision: > > - Extract method type desc > - Reviews > - Merge branch 'master' of https://github.com/openjdk/jdk into > fix/object-methods-profile > - Merge branch 'master' of https://github.com/openjdk/jdk into > fix/object-methods-profile > - Improve bench, add comment > - Fix profiling issue with record shared code > - Unsuccessful attempt to fix record regression Reran tier1-3. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27533#issuecomment-3424134705
