JDK-8349142 : [JMH] compiler.MergeLoadBench.getCharBV fails
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2025-01-31
  • Updated: 2025-02-10
  • Resolved: 2025-02-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25
25 b09Fixed
Related Reports
Causes :  
Relates :  
Description
Below test JMH tests fails java.lang.invoke.WrongMethodTypeException: cannot convert MethodHandle(VarHandle,byte[],int)char to (VarHandle,byte[],long)char

org.openjdk.bench.vm.compiler.MergeLoadBench.getCharBV
org.openjdk.bench.vm.compiler.MergeLoadBench.getCharLV

The test log snippet:

java.lang.invoke.WrongMethodTypeException: cannot convert MethodHandle(VarHandle,byte[],int)char to (VarHandle,byte[],long)char
	at java.base/java.lang.invoke.MethodHandle.asTypeUncached(MethodHandle.java:915)
	at java.base/java.lang.invoke.MethodHandle.setAsTypeCache(MethodHandle.java:900)
	at java.base/java.lang.invoke.MethodHandle.asType(MethodHandle.java:873)
	at org.openjdk.bench.vm.compiler.MergeLoadBench.getCharLV(MergeLoadBench.java:360)
	at org.openjdk.bench.vm.compiler.jmh_generated.MergeLoadBench_getCharLV_jmhTest.getCharLV_avgt_jmhStub(MergeLoadBench_getCharLV_jmhTest.java:190)
	at org.openjdk.bench.vm.compiler.jmh_generated.MergeLoadBench_getCharLV_jmhTest.getCharLV_AverageTime(MergeLoadBench_getCharLV_jmhTest.java:153)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:527)
	at org.openjdk.jmh.runner.BenchmarkHandler$BenchmarkTask.call(BenchmarkHandler.java:504)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:328)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:545)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:328)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1095)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:619)
	at java.base/java.lang.Thread.run(Thread.java:1447)
Comments
ILW = Test failure, two JMH benchmarks, no workaround = MLH = P4
03-02-2025

Changeset: 2cce5eeb Branch: master Author: SendaoYan <syan@openjdk.org> Date: 2025-02-02 02:46:16 +0000 URL: https://git.openjdk.org/jdk/commit/2cce5eeb092b68b4e4ce6a8289a8aa567f47c973
02-02-2025

I don't think reversal of that cause commit is necessary; in fact, this copy-pasta bug has been unnoticed until the Unsafe address long migration forces this bug to surface. The VH argument never required an unsafe base offset.
31-01-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23393 Date: 2025-01-31 15:26:28 +0000
31-01-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23392 Date: 2025-01-31 15:08:57 +0000
31-01-2025

Below code snippet can reproduce the failure: import java.lang.invoke.MethodHandles; import java.lang.invoke.VarHandle; import java.nio.ByteOrder; import jdk.internal.misc.Unsafe; public class GetCharLV { public static void main(String[] args) { VarHandle CHAR_L = MethodHandles.byteArrayViewVarHandle(char[].class, ByteOrder.LITTLE_ENDIAN); final int NUMBERS = 8192; final byte[] bytes4 = new byte[NUMBERS * 4]; char c = (char) CHAR_L.get(bytes4, Unsafe.ARRAY_BYTE_BASE_OFFSET); } }
31-01-2025

Seems regress by JDK-8344168
31-01-2025

I've confirmed that reverting commit fdfb68c8d0fddfe527291a7f4b75176c830dbb49 fixes the issue. Will mark that as the cause. Paging [~swen] Changing Unsafe.ARRAY_BYTE_BASE_OFFSET to long changes the type of the second argument to long, which can not be implicitly converted to int, resulting in a WMTE. Likely the second argument just needs a cast to int.
31-01-2025

Thanks for checking, [~jvernee]!
31-01-2025

[~syan] I think you mean https://bugs.openjdk.org/browse/JDK-8344168 ? My change is unrelated to the code in the benchmark.
31-01-2025

Paging [~jvernee]
31-01-2025