JDK-8191437 : AOT doesn't work easily after thread local handshakes
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-11-16
  • Updated: 2017-12-15
  • Resolved: 2017-11-30
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 10
10 b36Fixed
Related Reports
Relates :  
JDK-8189941 - Implementation JEP 312: Thread-local handshake
Description
The argument processing of AOT was changed with 
8189941: Implementation JEP 312: Thread-local handshake
because AOT doesn't yet support it. Previously UseAOT was on by default, and aot'ed java.base.so etc in jdl/lib were seamlessly loaded and used without any extra args. After 8189941, the only way to get AOT to work is to specify the AOT library explicitly for example: -XX:AOTLibrary=./build/linux-x64/images/jdk/lib/libjava.base-coop.so

The workaround for the time being to use AOT the old way is to use -XX:-ThreadLocalHandshakes.
Comments
Without knowing much about graal, the patch looks like expected.
24-11-2017
http://cr.openjdk.java.net/~dlong/8191437/webrev/
24-11-2017
Sounds good, you have some extra tests here open/test/hotspot/jtreg/:hotspot_handshake
23-11-2017
I have it working for x64.
23-11-2017
It's a bug and it'd be nice to fix it in 10.
23-11-2017
Initial ILW = AOT is disabled if AOTLibrary not explicitly specified; common case with aot; -XX:-ThreadLocalHandshakes, -XX:AOTLibrary = MML= P4 Or can this be an enhancement task and not bug? (targeting to 11 for now, please change if required)
22-11-2017
"But, yes, the best solution would be to implement TLH in Graal and therefore in AOT." Agreed. "Maybe transfer ownership of the code to OpenJDK first.." That would help.
17-11-2017
Maybe transfer ownership of the code to OpenJDK first..
17-11-2017
I assume changes were made to C1 and C2 to support TLH. Whoever made those changes should have the first stab at making the necessary changes to Graal, asking for Labs support when needed.
16-11-2017
No, it actually looks for known library names in the JDK directory. A quick temporary fix would be to look for these libraries during arg processing. They won't be there by default - the user has to put them there. But, yes, the best solution would be to implement TLH in Graal and therefore in AOT.
16-11-2017
In working through the TLH argument processing we were told that AOT is only _really_ on if UseAOT is true AND there is a library specified. We have two incompatible features that both want to be on by default.
16-11-2017
Other (real) solution would be to implement TL safepoints in Graal. [~dnsimon], would anybody from the Labs be interested to work on that?
16-11-2017
The problem lies here: + bool aot_enabled = UseAOT && AOTLibrary != NULL; AOT is disabled if AOTLibrary is not specified. This is incorrect behavior. AOT searches for libraries in $JAVA_HOME/jdk/lib during its initialization (see AOTLoader::initialize() ). This happens after arguments processing, and it'd be hard to work around it. One possible fix would be to search for possible libraries during argument processing and enable AOT if any are found.
16-11-2017