RFR: 8350617: Improve MethodHandles.tableSwitch and remove intrinsicData

Jorn Vernee jvernee at openjdk.org
Tue Mar 4 14:32:56 UTC 2025


On Tue, 25 Feb 2025 02:45:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove the intrinsicData field. We can obtain this from the customized MH when we spin ultra-customized lambda forms. In the long run, we aim to remove this intrinsic if there is no regression for call site sharing.
> 
> The existing tableSwitch combinator's LF is unnecessarily complex. This patch also simplifies the tableSwitch combinator.
> 
> Note that I was forced to add `@ForceInline` on immutable lists due to regressions in `MethodHandlesTableSwitchRandom` with `sorted == true`, which eliminates the regression. Otherwise, all benchmark results are the same. Tested java/lang/invoke.

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 628:

> 626:                                         continue;
> 627:                                     }
> 628:                                     break; // Only inline target MHs if this is customized

I think this could be problematic, as we typically only customize the root method handle in a chain. So, if a table switch handle is used with another combinator, we will never benefit from the intrinsic.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7664:

> 7662:             if (mh.type() != expectedType)
> 7663:                 throw new IllegalArgumentException(
> 7664:                     "Some targets do not have the expected type " + expectedType + ": " + caseActions);

I think we should avoid changing the exception messages here, since it's observable from the outside.

FWIW, one of the downsides of only printing out a single method handle, is that a user can't tell which method handle in the list was problematic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23763#discussion_r1979460526
PR Review Comment: https://git.openjdk.org/jdk/pull/23763#discussion_r1979537776


More information about the core-libs-dev mailing list