RFR: 8367320: Sort cpu/x86 includes [v2]
Stefan Karlsson
stefank at openjdk.org
Mon Sep 15 05:58:17 UTC 2025
On Fri, 12 Sep 2025 18:43:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:
>> Thanks for the detailed summary, indeed it looks like my initial proposal is not enough to address all cases. I'll think about it and go through the cases as you suggested.
>>
>> For the time being, I moved #27259 to draft.
>
>> Another think one has to consider is if the includes are written so that the platform files can be included stand-alone or not
>
> If a header file (hpp or inline.hpp) can not be included stand alone, I would even argue it's not really a proper header file.
>
> Even though `#include` is indeed just copy-and-paste, the use of `#include CPU_HEADER(frame)` still feels like an overuse of C/C++ header includes. I think those "improper" header files can "stand out" if they are named differently from ordinary one, maybe sth like `frame_X.partial.hpp`. My 2c.
FWIW, while writing the above and looking through the files I had a similar reaction to what Albert writes here. We would still need to differentiate between .hpp and .inline.hpp files. Maybe:
file.partial.hpp
file.partial.inline.hpp
Another interesting pattern we have can be found in the gc_globals.hpp and g1_globals.hpp files:
If you want the flags from g1_globals.hpp you must include gc_globals.hpp. g1_globals.hpp can be included stand-alone, but it won't do you much good because the declarations of the flags are generated by including gc_globals.hpp. Should g1_globals.hpp then be named g1_globals.partial.hpp?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27189#discussion_r2347943256
More information about the hotspot-dev
mailing list