On Fri, 8 Aug 2025 11:36:04 GMT, Francesco Andreuzzi <d...@openjdk.org> wrote:
>> 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.
>
> I followed this hint, the latest version of the script checks the `.d` files.
>
> Two observations:
> - The magic number is now `2460` (more includes are taken into account, which
> makes sense)
> - There is much less wiggle room, 2461 includes nothing, 2459 includes too
> much
> - Runtime does not seem to be affected negatively or positively
>
> If anybody is interested, this file contains the inclusion count for each
> source file:
> [inclusions_count.txt](https://github.com/user-attachments/files/21682561/inclusions_count.txt)
Something seems wrong with these numbers.
- There are 538 headers with include counts of 2460.
- There are only 1121 .o.cmdline files.
So how do we get include counts that are greater (by more than a factor of 2)
than the number of .d files?
Note that precompiled.hpp has an include count of 2456. There's 1 .d file that
depends on everything - BUILD_LIBJVM.d. That probably ought to be excluded
from counting, although I guess it should just add one to every file.
Also, precompiled.hpp has an include count of 2456, so not the maximum count,
but close. Which is itself weird that it wouldn't be the most included file.
But it's hard to guess what might be going on with that until the surprising
high include count > number of .d files is understood.
That include count listing would also be more useful of sorted by count.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26681#discussion_r2262874254
