JDK-8367346 : [lworld] VarHandleTestMethodHandleAccessValue.java fails with a timeout
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: repo-valhalla
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-09-10
  • Updated: 2025-09-26
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.
Other
repo-valhallaUnresolved
Related Reports
Causes :  
JDK-8357245 - [lworld] Improve performance of Flat array var handles
Relates :  
JDK-8367362 - ProblemList test VarHandleTestMethodHandleAccessValue.java
Sub Tasks
JDK-8367362 :  
ProblemList test VarHandleTestMethodHandleAccessValue.java - Resolved
Description
VarHandleTestMethodHandleAccessValue.java fails with a timeout.

One of the threads has the stack trace:

"MainThread" #34 [35075] prio=5 os_prio=31 cpu=119929.31ms elapsed=120.11s tid=0x0000000103025210 nid=35075 runnable  [0x0000000300e4d000]
   java.lang.Thread.State: RUNNABLE
Thread: 0x0000000103025210  [0x8903] State: _at_safepoint _at_poll_safepoint 0
   JavaThread state: _thread_blocked
	at jdk.internal.misc.Unsafe.newSpecialArray(java.base@25-lworld5ea/Native Method)
	at jdk.internal.misc.Unsafe.compareAndSetFlatValueAsBytes(java.base@25-lworld5ea/Unsafe.java:2871)
	at jdk.internal.misc.Unsafe.compareAndSetFlatValue(java.base@25-lworld5ea/Unsafe.java:1703)
	at jdk.internal.misc.Unsafe.weakCompareAndSetFlatValuePlain(java.base@25-lworld5ea/Unsafe.java:1821)
	at java.lang.invoke.VarHandleFlatValues$FieldInstanceReadWrite.weakCompareAndSetPlain(java.base@25-lworld5ea/VarHandleFlatValues.java:230)
	at java.lang.invoke.LambdaForm$DMH/0x00003f8001076400.invokeStatic(java.base@25-lworld5ea/LambdaForm$DMH)
	at java.lang.invoke.LambdaForm$MH/0x00003f8001081000.invoke(java.base@25-lworld5ea/LambdaForm$MH)
	at java.lang.invoke.LambdaForm$MH/0x00003f800107f000.invokeExact_MT(java.base@25-lworld5ea/LambdaForm$MH)
	at VarHandleTestMethodHandleAccessValue.testInstanceField(VarHandleTestMethodHandleAccessValue.java:221)
	at VarHandleTestMethodHandleAccessValue.lambda$accessTestCaseProvider$0(VarHandleTestMethodHandleAccessValue.java:91)
	at VarHandleTestMethodHandleAccessValue$$Lambda/0x00003f800106da08.action(Unknown Source)
	at VarHandleBaseTest$AccessTestCase.testAccess(VarHandleBaseTest.java:422)
	at VarHandleTestMethodHandleAccessValue.testAccess(VarHandleTestMethodHandleAccessValue.java:123)
Comments
I think the main cost may be the native downcall overhead associated with Unsafe's newSpecialArray, arrayIndexScale, and arrayBaseOffset - the old ones are class-bound features so they are not called frequently, while these 3 APIs are now hot and must have compiler intrinsics for them.
10-09-2025
Please evaluate.
10-09-2025