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. src/java.base/share/classes/java/lang/runtime/ObjectMethods.java line 327: > 325: .aload(0) // arg0.hashCode() - > bytecode subject to customized profiling > 326: .invoke(isInterface ? > Opcode.INVOKEINTERFACE : Opcode.INVOKEVIRTUAL, typeDesc, "hashCode", > MethodTypeDesc.of(CD_int), isInterface) > 327: .ireturn(); Suggestion: cob.aload(0) .ifnonnull(nonNullPath) .iconst_0() // null hash is 0 .ireturn() .labelBinding(nonNullPath) .aload(0) // arg0.hashCode() - bytecode subject to customized profiling .invoke(isInterface ? Opcode.INVOKEINTERFACE : Opcode.INVOKEVIRTUAL, typeDesc, "hashCode", MethodTypeDesc.of(CD_int), isInterface) .ireturn(); code style ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27533#discussion_r2402073613
