JDK-8199263 : Split interfaceSupport.hpp to not require including .inline.hpp files
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-03-07
  • Updated: 2019-06-20
  • Resolved: 2018-03-16
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
11 b07Fixed
Related Reports
Relates :  
JDK-8199279 - Remove IRT_ENTRY, IRT_LEAF, IRT_ENTRY_NO_ASYNC and IRT_END
Relates :  
JDK-8154079 - Catch incorrectly included .inline.hpp files
Sub Tasks
JDK-8199490 :  
Rename interfaceSupport.hpp to interfaceSupport.inline.hpp - Closed
Description
share/runtime/interfaceSupport.hpp:#include "runtime/handles.inline.hpp"
share/runtime/interfaceSupport.hpp:#include "runtime/safepointMechanism.inline.hpp"
share/runtime/interfaceSupport.hpp:#include "runtime/thread.inline.hpp" 

Fix this header to not require .inline.hpp files.
Comments
The file interfaceSupport.hpp has a set of classes and state transitions that are intended to be inlined in the caller. interfaceSupport.hpp also includes safepointMechanism.inline.hpp and handles.inline.hpp which breaks the coding standard. It is also included some header files, so it brings the inlined functions into these header files: share/prims/methodHandles.hpp:#include "runtime/interfaceSupport.hpp" share/prims/whitebox.hpp:#include "runtime/interfaceSupport.hpp" share/prims/jvmtiEnter.hpp:#include "runtime/interfaceSupport.hpp" share/ci/ciUtilities.hpp:#include "runtime/interfaceSupport.hpp" First step is to rename interfaceSupport.hpp to interfaceSupport.inline.hpp, and modify the #include statements. Second, create a ciUtilities.inline.hpp, whitebox.inline.hpp to include transition declarations and include interfaceSupport.inline.hpp. jvmtiEnter.hpp was just renamed jvmtiEnter.inline.hpp. The interfaceSupport.hpp was removed from methodHanldles.hpp and the transitive #includes were added where needed.
13-03-2018
Further cleaning showed that the following requires thread.inline.hpp: ~ThreadInVMfromJava() { if (_thread->stack_yellow_reserved_zone_disabled()) { $ grep -r stack_yellow_reserved_zone_disabled src/hotspot/ src/hotspot/share/runtime/thread.hpp: inline bool stack_yellow_reserved_zone_disabled(); src/hotspot/share/runtime/interfaceSupport.hpp: if (_thread->stack_yellow_reserved_zone_disabled()) { src/hotspot/share/runtime/interfaceSupport.hpp: if (_thread->stack_yellow_reserved_zone_disabled()) { src/hotspot/share/runtime/thread.inline.hpp:inline bool JavaThread::stack_yellow_reserved_zone_disabled() {
08-03-2018
Since we already have a performance regression for safepoint, I'm not terrible happy about we not inlining the poll checks. I did quick measurement of arming 1000 threads, with not in-lining the the arming it takes 3x longer. (Still very quick)
08-03-2018
Moving safepointMechanism.inline.hpp files to safepointMechanism.cpp allows removing .inline.hpp files from interfaceSupport.hpp. Does this matter for performance? It seems that they are infrequently called and call non-inlined functions also. The runtime safepointing mechanism should not be as important for performance as the mechanism in JIT generated code. open webrev at http://cr.openjdk.java.net/~coleenp/8199263.01/webrev Also interfaceSupport.hpp is included by a lot of files that don't require it (without precompiled headers).
08-03-2018