RFR: 8365053: Refresh hotspot precompiled.hpp with headers based on current frequency [v14]

[Erik Joelsson]

On Mon, 25 Aug 2025 17:56:18 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>>> Also, as a side note, I think we need to look more into -ftime-trace. We most likely have some code that is very heavy to compile that can be simplified for the compiler without sacrificing runtime performance. If would be interesting to compile all JDK native code with that flag...
>> 
>> I created a ticket with some details to follow up: https://bugs.openjdk.org/browse/JDK-8366111
>> 
>>> Apart from that, I still share Kim's worry that the platform with the most potential impact is Windows, and we have no numbers at all there. Can you arrange to test so we at least to not have any regressions there? And also check how the performance changes if you also manually include the same set of inline files as is currently in the PCH.
>> 
>> Might take a while as I don't really work on Windows, I'll try to set up some EC2 with the tooling in the coming days.
>
>> Apart from that, I still share Kim's worry that the platform with the most potential impact is Windows, and we have no numbers at all there.
> 
> I did run a quick comparison on Windows with an early version of this patch and it was basically a wash compared to before (slightly slower but could just be variance). I just reran with the latest patch and saw a slight improvement. Could still just be variance, but here are the numbers for running `make hotspot` immediately after `make clean-hotspot` to really isolate just the hotspot build. I warmed up caches by first building hotspot from scratch before cleaning.
> 
> Baseline (@57434c73eac9bd6557b09d4a057e3a2a18f382b4): 4m38
> This branch (@2f97d57b55fc838b30cf0d730c6119bf97749c6b): 4m30, 4m33
> 
> I only did one baseline run and then 2 on the branch. It's enough to show no regression.

> I added them back in [4a2ff56](https://github.com/openjdk/jdk/commit/4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f), there's only two of them since the others are now always included. @erikj79 any chance you could try once again and see if [4a2ff56](https://github.com/openjdk/jdk/commit/4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f) has any effect on build time?

I ran two more times:

This branch (@4a2ff5649ba9dc6a024aeb7577d630a3fefcbe4f): 4m37, 4m29

So basically unchanged.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26681#issuecomment-3221794432