On Fri, 8 Aug 2025 00:43:27 GMT, Francesco Andreuzzi <d...@openjdk.org> wrote:
>> In this PR I propose to refresh the included headers in hotspot
>> `precompiled.hpp`. The current set of precompiled headers was refreshed in
>> 2018, 7 years ago. I repeated the same operations and measurements after
>> refreshing the set of precompiled headers according to the current usage
>> frequency.
>>
>> These are the results I observed. Depending on the platform, the improvement
>> is between 10 and 20% in terms of total work (user+sys). The results are in
>> seconds.
>>
>>
>> linux-x64 GCC
>> master real 81.39 user 3352.15 sys 287.49
>> JDK-8365053 real 81.94 user 3030.24 sys 295.82
>>
>> linux-x64 Clang
>> master real 43.44 user 2082.93 sys 130.70
>> JDK-8365053 real 38.44 user 1723.80 sys 117.68
>>
>> linux-aarch64 GCC
>> master real 1188.08 user 2015.22 sys 175.53
>> JDK-8365053 real 1019.85 user 1667.45 sys 171.86
>>
>> linux-aarch64 clang
>> master real 981.77 user 1645.05 sys 118.60
>> JDK-8365053 real 791.96 user 1262.92 sys 101.50
>
> Francesco Andreuzzi has updated the pull request incrementally with one
> additional commit since the last revision:
>
> script. update
Changes requested by kbarrett (Reviewer).
src/hotspot/share/precompiled/precompiled.hpp line 29:
> 27:
> 28: // These header files are included in at least 130 C++ files, as of
> 29: // measurements made in August 2025.
I don't think there's anything particularly special about the number 130.
Another thing to consider when a header file has a high include count is
whether it's being overincluded. We've had lots of those, and some folks
occasionally try to poke at that problem. Some of the removals here look like
they might be a result of such efforts.
Still another thing to consider is the cost of inclusion. Some files may just
be a lot more expensive to process and benefit more for being precompiled.
File size can be an indicator, but there are others. Unfortunately, I don't
know of a good way to measure this.
src/hotspot/share/precompiled/precompiled.hpp line 70:
> 68: #include "utilities/ticks.hpp"
> 69:
> 70: #ifdef TARGET_COMPILER_visCPP
All of the reported testing was on Linux. These were included specifically
because measurements
said their inclusion here was beneficial. And my recollection from previous
discussions is that
Visual Studio may be the compiler where precompiled headers are most beneficial.
src/utils/PrecompiledHeaders/PrecompiledHeaders.java line 70:
> 68: // Count inclusion times for each header
> 69: Map<String, Integer> occurrences = new HashMap<>();
> 70: try (Stream<Path> paths = Files.walk(hotspotPath)) {
I think walking the source tree is the wrong approach to gathering the data
about include counts. I think better is to do a build and then look at the
files <builddir>/hotspot/variant-server/libjvm/objs/*.d. From that one can build
a completely accurate count of the transitive inclusions.
-------------
PR Review: https://git.openjdk.org/jdk/pull/26681#pullrequestreview-3099600154
PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262050884
PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262055386
PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262041141
