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

[Stefan Karlsson]

Hi Coleen,

Not sure why this is a Pre-RFR instead of a RFR. Most of this looks good 
to me.

I'd prefer if you removed the .inline.hpp files from precompiled.hpp. We 
could also do it as a separate cleanup if you don't want to retest this 
patch.

Thanks,
StefanK


On 2018-03-13 12:50, 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 VM_ENTRY. 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
> 
>