JDK-8206960 : [Graal] serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor tests fail
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 11,12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-07-10
  • Updated: 2024-01-29
  • Resolved: 2018-07-12
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 11 JDK 12
11 b23Fixed 12Fixed
Related Reports
Duplicate :  
JDK-8206936 - Tests serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor* doesn't work with additional VM options
Description
Following tests fail when running with Graal:
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCSerialTest.java
 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorEventOnOffTest.java

To reproduce run jtreg with
 -vmoptions:"-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal"
Comments
[~epavlova] are there plans to fix the tests properly so they work with Graal?
02-08-2019
I let you decide if you want to continue on this bug but I think it's a separate issue due to not being at tip. Perhaps we could take this off this bug tracking (or create a new one and work there)?
31-08-2018
Finally I found some time to apply the patch and run the tests. These two still fail: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorEventOnOffTest.java serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorTest.java
31-08-2018
Yes I would imagine it is the same issue. VMEventsTest is really most likely the same issue. I could confirm the other two if you go in libHeapMonitorTest.c and enable the PRINT_OUT macro. Then run the two HeapMonitorEventOnOffTest and HeapMonitorTest. Look for outputs that look like: Comparing: Names: actuallyAllocate and actuallyAllocate Signatures: ()I and ()I File name: HeapMonitor.java and HeapMonitor.java Lines: 92 and 93 Result is 1
20-08-2018
Unfortunately we at Twitter are not on latest 11 yet and there is no easy way for us to update now. But currently, without this patch, I am seeing these 3 fail: serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorEventOnOffTest.java: Checking storage count 407 java.lang.RuntimeException: Failed to find the traces after allocating with enabled events. serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorTest.java: Checking storage count 354 java.lang.RuntimeException: Events not found with the right frames. serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java: Obtained: 32769 - 32769 - 74414 java.lang.RuntimeException: Error rate is over the accepted rate: 127.08657572705911: 32769 , 74414 Do you think these are the same issue?
20-08-2018
URL: http://hg.openjdk.java.net/jdk/jdk11/rev/bf686c47c109 User: sspitsyn Date: 2018-07-12 19:39:29 +0000
12-07-2018
Fixed all issues via : http://cr.openjdk.java.net/~jcbeyler/8206960/webrev.00/ What I've done is: - Disable the VMEvent test since Graal does not support the DisableIntrinsic flag - Changed the test framework to look if Graal is being used; if graal is being used I don't check the lines but do check the method frames so that we ensure correctness at the method call level at least even for graal (better than just disabling the tests in my mind) This passes all tests with Graal except the CMS test which is being pushed via JDK-8205643
11-07-2018
Cough cough, it's by hand due to it being a test. Sounds like I'll disable the test there too for Graal since it can be "imprecise" and add a comment as to why. Thanks for the extra information! I might take the time to at least add a "check the methods" not the lines for the stacktrace for graal so that we have at least a bit of coverage for Graal. Seems like I can create a webrev handling all these items then.
11-07-2018
Regarding the line number difference, Graal uses imprecise BCIs at uncommon traps. That is, it will often restart in the interpreter at some point before the bytecode instruction causing the trap (but after the last side effect). I don't know how heap monitoring Frames are created but this would most likely explain the line number difference.
11-07-2018
Then my current thought process is to turn off the test for Graal since it does not support it. For the other tests, any idea why with Graal the line numbering of a stack trace would differ?
11-07-2018
Correct - Graal does not currently support DisableIntrinsic. It could be implemented quite easily here: https://github.com/AdoptOpenJDK/openjdk-jdk/blob/63e954381d81e5c20a2507e9d34a067fbd0a2db0/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotInvocationPlugins.java#L62
11-07-2018
Thanks for the analysis, I've re-opened the bug. Please assign back to us if there is evidence that this is a compiler bug. I don't think Graal respects the DisableIntrinsic flag. [~dnsimon], could you please confirm?
11-07-2018
(I would reopen this until those questions are answered and I check if the line number is not Graal specific)
10-07-2018
Not an exact duplicate: - For some reason, serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorEventOnOffTest.java + the GCSerialTest is failing because of a line difference when using Graal - Reproduce to see: find the define PRINT_OUT in libHeapMonitorTest.c and set it to 1; then you would see: Comparing: Names: actuallyAllocate and actuallyAllocate Signatures: ()I and ()I File name: HeapMonitor.java and HeapMonitor.java Lines: 92 and 93 Result is 1 When using Graal, the obtained line is 92 instead of 93, which is strange. - For the VMEventsTest, for some reason with Graal, the clone method is being called only half the time instead. Does Graal not respect the flag: -XX:DisableIntrinsic=_clone?
10-07-2018
This is a duplicate of JDK-8206936.
10-07-2018