RFR: 8349638: Build libjdwp with SIZE optimization

[Magnus Ihse Bursie]

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

Hi, sorry for my absence. Some general comments based on the discussions here:

1) As Matthias has correctly understood, there is very little known about the reasoning of the current optimization levels. They were all done much prior to me joining the build team, and the rewriting of the build system. The current "optimization levels" where the result of trying to reverse-engineering what was de facto done in the old build system, and trying to make some kind of sense out of it. I think we can safely assume that there are no real well-founded reasons for any of the current optimization flags, except for specific exceptions like Hotspot.

2) We have been very cautious in changing these flags (including how we copied the old flags precisely from the old build system), but I've more and more come to the conclusion that this conversative approach is not really helpful. Changing optimization flags is most likely not more likely to provoke unforeseen problems than upgrading the compiler, and that is something we do regularly.

3) Furthermore, it is not by any means clear that e.g. -Os on gcc 5 means even close to the same thing, in terms of generated code, as -Os on gcc 14. The *intention* is clear -- i.e. optimize for size, but I think it would be a reasonable assumption that the actually generated code (which is what we care about in the end) will not share much similarities between now and the time at which the specific compiler optimization flag was chosen.

So, in essence, I highly support Matthias's work on updating these flags. More specifically, I think it will make sense for the most cases to use SIZE instead of LOW. My general feeling, from working with other optimization efforts in the past, is that optimizing for size in most cases also renders a benefit in speed, most likely arising from the code fitting better in caches, and perhaps doing shorter jumps, so it is typically a win-win scenario.

Otoh, we could probably raise the bar and optimize for performance (HIGH or HIGHEST) on several libraries that are currently LOW, even if the consequences are less clear. Most such libraries are only heavily used in specialized scenarios. If these scenarios are *only* microbenchmarks, then we should not care. But if there is some chance that a real application has a real payload that involves stressing some native library, then I see no reason *not* to increase the optimization level, if we can prove (with microbenchmarks) that this does indeed help performance.

Then finally there is a third aspect, on top of end-user application performance and JDK footprint, and that is the build time. More optimization tend to mean longer build times. In particular, LTO has been known to be very time consuming. (This might have changed with some of the recent efforts in improving LTO; I'm not fully up to speed in that area, but in any case, we're not using any new fancy methods in the JDK as of now.)

I don't doubt that LTO will make wonders for the size, and probably performance, of any native library. But it is also likely to come at a significant increase in build time for these libraries. How much that matters on the whole -- if there are no build dependencies waiting for the library, and we can parallelize the build reasonably, and given that we do a lot more than just compile and link native libraries -- I don't know.

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2682282702