RFR: 8349638: Build libjdwp with SIZE optimization
Magnus Ihse Bursie
ihse at openjdk.org
Tue Feb 25 15:11:57 UTC 2025
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 .
I think it might be worth trying to take a more structured approach to the optimizations used. Maybe setup a wiki page with all native libraries, what current optimization levels they use, and what the difference in size would be for e.g. SIZE and HIGH instead. Ideally, we would also have some kind of microbenchmark associated with each library that could say anything about the performance of the library, but that is probably not realistic in most cases. But I guess that people familiar with the library can make some educated guess about the performance sensitivity of the libraries, and what would stress them.
Furthermore, I think we can definitely consider changes in the build system to support some of the requests that have arisen here, like allowing JDK libraries (apart from Hotspot) to allow LTO, or to have a way to override optimization levels for JDK libraries from the configure command line, similar to the JVM feature `opt-size`.
I am also open to reconsidering the entire idea of "optimization levels" the way it is currently implemented. Developers tend to think in terms of `-O2`, and our named optimization levels just inserts an extra layer of uncertainty ("what does `HIGHEST` really mean?). A problem is of course that different compilers have different ways of expressing optimization (most clearly how the Microsoft VS compiler differs from gcc/clang), but then again, maybe that just means that we should express this as:
OPT_gcc_clang := -O1, \
OPT_microsoft := -O2. \
since it is not obvious that there really is a good way to package different optimization flags for different compilers that make sense for all libraries. Our current code assumes this is the case, but this does not necessarily have to be true.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2682315156
More information about the build-dev
mailing list