RFC: Organising .inline.hpp and .hpp includes

Stefan Karlsson stefan.karlsson at oracle.com
Thu Aug 11 08:21:26 UTC 2016


Hi David,


On 2016-08-11 09:31, David Holmes wrote:
> I'm trying to tackle the incorrect inclusion of .hpp files instead of 
> .inline.hpp starting with the use of atomic.inline.hpp ref:
>
> https://bugs.openjdk.java.net/browse/JDK-8157907
>
> The basic rules would seem to be:
>
> If class Foo has inline methods that need to call the inline Atomic 
> methods then:
>
> - Those methods should be defined in foo.inline.hpp
>
>    inline void Foo::a() { /* do stuff with atomics */ }
>
> - foo.hpp declares those methods:
>
>    inline void a();
>
> - foo.inline.hpp includes foo.hpp
> - foo.inline.hpp includes atomic.inline.hpp
> - foo.cpp includes foo.inline.hpp
>
> Do have agreement so far?

Yes.

>
> Now suppose we have class Bar which uses Foo.
>
> - bar.cpp should include foo.inline.hpp
> - If bar.hpp only references Foo but doesn't need to see a full 
> definition then bar.hpp can forward declare Foo
> - If bar.hpp defines inline methods that require full access to Foo 
> then either:
>
> a) bar.hpp includes foo.inline.hpp; or
> b) The inline functions of Bar are themselves moved to bar.inline.hpp 
> which includes foo.inline.hpp
>
> I think there was general opinion that (a) is undesirable, and that 
> (b) is preferable - is that right?

Yes.

Alternatively, if inlining isn't needed, place these functions in bar.cpp.

>
> What I am finding is that the fan out of applying (b) is rather large 
> - to the point where we may end up having x.hpp, x.inline.hpp and 
> x.cpp variants for very many x!

Yes, that's what I've also seen while investigating:

https://bugs.openjdk.java.net/browse/JDK-8154079
http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022626.html

I have an updated version that works with and without precompiled headers:
http://cr.openjdk.java.net/~stefank/8154079/webrev.02/

Regarding atomic.inline.hpp and the atomic_<os_cpu>.inline.hpp files, 
these files typically don't have a lot of dependencies on other header 
files and a pragmatic way forward could be to even further minimize 
those dependencies and move the implementation into atomic_<os_cpu>.hpp 
files and get rid of atomic.inline.hpp. I know that goes against the 
guidelines mentioned above, but it's an alternative to use if the fan 
out becomes too large.

>
>
> Just to add another dimension to this, what should precompiled.hpp 
> include? I would assume the .inline.hpp files right?

I would prefer if we got rid of the .inline.hpp files from precompiled.hpp.

Thanks,
StefanK

>
> Thanks,
> David



More information about the hotspot-dev mailing list