Pre-RFR (L) 8199263: Split interfaceSupport.hpp to not require including .inline.hpp files
david.holmes at oracle.com
Tue Mar 13 22:00:02 UTC 2018
On 14/03/2018 12:00 AM, coleen.phillimore at oracle.com wrote:
> On 3/13/18 8:55 AM, Stefan Karlsson wrote:
>> 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.
> Let's do that separately. I didn't know what we wanted to do for
> precompiled.hpp honestly.
I'd like to understand how .inline.hpp files work with PCH. If they can
be precompiled then I would think we want to keep them in
precompiled.hpp. If pre-compiling is meaningless for .inline.hpp then we
should remove them as clutter.
I don't expected precompiled.hpp to be subject to the ".hpp can't
include .inline.hpp" rule.
I hope to look at this soon as well.
>> 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
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8199263
>>> local webrev at
>>> Thanks to Stefan for his help with this.
More information about the hotspot-dev