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

Stefan Karlsson stefan.karlsson at oracle.com
Thu Mar 15 12:10:29 UTC 2018

Looks good.


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 
>>>> 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

More information about the hotspot-dev mailing list