JDK-8205824 : Update Graal
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-06-26
  • Updated: 2018-08-16
  • Resolved: 2018-06-28
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 b20Fixed 12Fixed
Related Reports
Duplicate :  
JDK-8204855 - [JVMCI][Graal] make JVMCI API changes necessary to support libgraal
Relates :  
JDK-8202698 - Update Graal for JEP 181 - Nest-based access control
Relates :  
JDK-8206992 - Update Graal
Relates :  
JDK-8204855 - [JVMCI][Graal] make JVMCI API changes necessary to support libgraal
Description
Pull several Graal's fixes and JVMCI API update
JDK-8204914:��Apache Spark based test fails with Graal enabled
JDK-8202698:��Update Graal for JEP 181 - Nest-based access control
JDK-8204855:��[JVMCI][Graal] make JVMCI API changes necessary to support libgraal

8db1309ed86 Tue Jun 26 18:58:12 2018 -0700      Christian Wimmer [GR-10546] Lock elimination can only combine locks with same lock depth.
f07242f9033 Mon Jun 25 03:06:20 2018 -0700            Doug Simon [GR-10536] Fixed stamp folding bug in ReverseBytesNode.
7af3760ef05 Mon Jun 25 00:32:17 2018 -0700            Doug Simon [GR-10539] Update CheckGraalIntrinsics for AArch64.
3ff06d16172 Fri Jun 22 04:42:17 2018 -0700            Doug Simon [GR-10514] Use whitelist for GCs supported by Graal.
70e00cbb25b Wed Jun 20 17:25:47 2018 -0700          Igor Veresov [GR-10493] Disable fast TLAB refill on JDK11.
e4aa55e6691 Wed Jun 20 10:27:09 2018 -0700         Tom Rodriguez [GR-10468] Correct signature of validate_object.
edb9db1e6b0 Tue Jun 19 14:09:51 2018 -0700            Oleg Pliss [GR-10170] When possible, perform null check on compressed pointers.
cce029d727e Tue Jun 19 10:42:32 2018 -0700       Vojin Jovanovic [GR-10426] Correct probabilities for NPE checks in native-image.
dede8791b18 Fri Jun 15 20:40:16 2018 -0700            Oleg Pliss [GR-10414] Iterative implementation of IsNullNode.canonicalized.
2bcfb0bff18 Fri Jun 15 00:33:45 2018 -0700         Matteo Murgia [GR-9894] Dump per compilation statistics.
d69c5cc7c49 Thu Jun 14 17:34:48 2018 -0700            Oleg Pliss [GR-9162] Implement linear pointer compression/uncompression.
Comments
I'm looking into it now. There's seems to be some kind of serious breakage in the updategraalinopenjdk script for me. I don't think it's related to the problems I expected to see though. It seems to be deleting the entirety of Graal.
10-07-2018
I noticed that, while trying to use 'mx updategraalinopenjdk' for changes I want to get into JDK. If filed JDK-8206992 and assigned it to you. Please put the instructions for reaching a reasonable state there.
10-07-2018
I"ve pushed a tag this changeset. 8db1309ed86 | 2018-06-26 18:58:12 -0700 | [GR-10546] Lock elimination can only combine locks with same lock depth. | Christian Wimmer (tag: JDK-8205824) It's not completely accurate because the actual Graal changes for the JVMCI API were pushed later, so the next Graal update will have to be done a little carefully. I can probably do that next time it's required or at least explain how to get into a reasonable state.
10-07-2018
[~never] We need a JDK-8205824 tag in Graal for this.
09-07-2018
Final pre-integration tier1 testing passed clean.
27-06-2018
Thank you, Katya.
27-06-2018
Based on this 8204855_2 testing "passed". A lot of tests failed before with Graal but bugs were not filed. Only new issue com/sun/jdi/PopAsynchronousTest.java which can be investigated later.
27-06-2018
vmTestbase/nsk/jvmti/PopFrame/popframe005/TestDescription.java failed with: TEST FAILED: finally block was executed after popping TEST FAILED: the lockObj[0]'s monitor became free too early TEST FAILED: Lock acquired by a frame, different from the popped one, was released when the popped frame had been popped Not new failure - happened before. Need to file a bug.
27-06-2018
vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t001/TestDescription.java Not new failure - happened before. Need to file a bug.
27-06-2018
vmTestbase/nsk/jvmti/PopFrame/popframe001/TestDescription.java failed: TEST FAILED: a tested frame has not been really popped. Not new failure - happened before. Need to file a bug.
27-06-2018
Next 3 tests failed before with Graal. Not new failure. Need to file a bug. serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorVMEventsTest.java serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCSerialTest.java serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorGCParallelTest.java serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorEventOnOffTest.java
27-06-2018
serviceability/jvmti/TestLambdaFormRetransformation.java not new - happened before. Need to file a bug.
27-06-2018
> Based on this I would say 8204855_1 passed. [~iignatyev] Igor do you agree? [~kvn] I agree w/ your analysis of 8204855_1 results.
27-06-2018
vmTestbase/nsk/stress/strace/strace003.java happened before. Could be JDK-8205562.
27-06-2018
vmTestbase/nsk/stress/except/except004.java timed out - happened before. Not new failure.
27-06-2018
java/lang/ref/ReachabilityFenceTest.java failed due to JDK-8146090. Also Graal is not used because it was run with XX:TieredStopAtLevel=3.
27-06-2018
com/sun/jdi/PopAsynchronousTest.java failed with: # Internal Error (t:/workspace/open/src/hotspot/share/runtime/thread.cpp:3123), pid=10012, tid=3864 # assert(_popframe_preserved_args == 0LL) failed: should not wipe out old PopFrame preserved arguments I attached JTwork_com_sun_jdi_PopAsynchronousTest_hs_err_pid10012.log file but it is difficult to say what went wrong.
27-06-2018
java/lang/Class/GetPackageBootLoaderChildLayer.java - should not be run with Graal because it uses --limit-modules flag which exclude JVMCI and Graal modules. It will fail with: jdk.vm.ci.common.JVMCIError: JVMCI compiler 'graal' not found On Windows GetPackageBootLoaderChildLayer.java test also causes crash which will be fixed in this changes: # Internal Error (t:/workspace/open/src/hotspot/os/windows/os_windows.cpp:3514), pid=708, tid=7592 # assert(!thread->is_Java_thread()) failed: must not be java thread On 6/27/18 9:40 AM, Tom Rodriguez wrote: > This looks like a long standing bug where a fix was made in 9 but not in 8 and then code from 8 was copied back into 9. Should I go ahead and restore the setting of true in my fix?
27-06-2018
Testing 8204855_2 (hs-tier4-graal,hs-tier5-graal) gc/g1/mixedgc/TestOldGenCollectionUsage.java - failed before. We should file a bug. Doug said "test seems to be based on the assumption that the compiler performs no allocation (obviously not true for Graal).
27-06-2018
Testing 8204855_1 (jdk-tier1,hs-tier1,hs-tier2,hs-tier3) have few failures: serviceability/sa/TestHeapDumpForLargeArray.java - not new. History shows that it failed before. vmTestbase/metaspace/stressDictionary/StressDictionary.java time out - JDK-8204264 4 serviceability tests failed before. Some are due to JDK-8193639 serviceability/sa/ClhsdbPstack.java serviceability/sa/ClhsdbPrintAs.java serviceability/sa/ClhsdbPrintAll.java serviceability/sa/ClhsdbJdis.java Based on this I would say 8204855_1 passed. [~iignatyev] Igor do you agree?
27-06-2018
Based on analysis and history of failures I would say JCK testing passed - no new failures.
27-06-2018
tier4-graal testing have 2 jvmti failures but they are not new - history shows that they fail with current JDK for month now vmTestbase/nsk/jvmti/scenarios/sampling/SP02/sp02t001/TestDescription.java vmTestbase/nsk/jvmti/PopFrame/popframe001/TestDescription.java
27-06-2018
http://cr.openjdk.java.net/~never/8205824/webrev
27-06-2018
initial ILW = highest from related tasks = P2
27-06-2018