On Fri, 10 Oct 2025 16:14:54 GMT, Jorn Vernee <[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. > > src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 213: > >> 211: var type = getter.type().returnType(); >> 212: if (isMonomorphic(type)) { >> 213: equalators[i] = equalator(lookup, type); > > Do we also have tests that test this code path now? `final` class seems like > it might be rare in tests. This should be covered. All primitives and record-valued components use this path. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27533#discussion_r2446045708
