RFR (L) 8199263: Split interfaceSupport.hpp to not require including .inline.hpp files (original) (raw)

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Wed Mar 14 16:23:35 UTC 2018

Thank you for reviewing, Robbin! Coleen

On 3/14/18 12:04 PM, Robbin Ehn wrote:

Looks good, thanks for fixing.

/Robbin On 2018-03-14 17:01, coleen.phillimore at oracle.com wrote:

I had to include and out-line some functions that create Handles, where handles.inline.hpp is not transitively included via interfaceSupport.hpp anymore.  Thanks to Stefan for finding these for me. This is the incremental webrev: http://cr.openjdk.java.net/~coleenp/8199263.03.incr/webrev/index.html And full webrev: http://cr.openjdk.java.net/~coleenp/8199263.03/webrev/index.html This passes mach5 tier1 on Oracle platforms. Thanks, Coleen On 3/14/18 8:48 AM, coleen.phillimore at oracle.com wrote:

Hi, this is broken with the inline Handle constructor, so please disregard for now.  I have to add more handles.inline.hpp includes since they're not transitively included by interfaceSupport.hpp. thanks, Coleen On 3/13/18 9:01 AM, coleen.phillimore at oracle.com wrote: Sorry, this is the correct webrev: http://cr.openjdk.java.net/~coleenp/8199263.02/webrev/index.html

Coleen On 3/13/18 7:50 AM, coleen.phillimore at oracle.com wrote: Summary: interfaceSupport.hpp is an inline file so moved to interfaceSupport.inline.hpp and stopped including it in .hpp files

90% of this change is renaming interfaceSupport.hpp to interfaceSupport.inline.hpp.   I tried to see if all of these files needed this header and the answer was yes.   A surprising (to me!) number of files have thread state transitions. Some of interesting part of this change is adding ciUtilities.inline.hpp to include interfaceSupport.inline.hpp for VMENTRY. whitebox.inline.hpp was added for the same reason. jvmtiEnter.hpp was renamed jvmtiEnter.inline.hpp because it includes interfaceSupport.inline.hpp, and is only included in cpp files. The rest of the changes were to add back includes that are not pulled in by header files including interfaceSupport.hpp, like gcLocker.hpp and of course handles.inline.hpp. This probably overlaps some of Volker's patch.  Can this be tested on other platforms that we don't have? Hopefully, at the end of all this we have more clean header files so that transitive includes don't make the jvm build on one platform but not the next.  I think that's the goal of all of this work. This was tested with Oracle platforms (linux-x64, solaris-sparcv9, macosx-x64, windows-x64) in the mach5 tier1 and 2.   I built this locally without precompiled headers (my default setting of course) on linux-x64. bug link https://bugs.openjdk.java.net/browse/JDK-8199263 local webrev at http://oklahoma.us.oracle.com/~cphillim/webrev/8199263.02/webrev Thanks to Stefan for his help with this. Thanks, Coleen

More information about the hotspot-dev mailing list