On Tue, 6 Jan 2026 08:28:35 GMT, Aleksey Shipilev <[email protected]> wrote:
> [JDK-8374507](https://bugs.openjdk.org/browse/JDK-8374507) forced me to look > into debug info sizes again. And I remembered that GCC actually have > debug-level support, which can select what kind of diagnostic data is in the > debug info. See: > https://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Debugging-Options.html > > Allowing users to configure the debug level allows two major deviations from > the default level (2): > level=1: significantly reduce the debug info size, but still allow backtrace > reconstruction > level=3: add even more debugging info, like macro expansion, into the debug > data > > This RFE upstreams the variant the patch that I have been using in > builds.shipilev.net binaries: the fastdebug variants there are done with GCC > level=1, greatly optimizing the debug binary sizes, while still maintaining > the major benefit of debug binaries -- rich crash diagnostics. > > I threw in this option into current GHA builds to conserve more disk space on > runners and/or transfers. > > I am open for bikeshedding on the option name :) Motivational improvements in debug info sizes: $ ls -sh ./build/linux-x86_64-server-fastdebug/images/jdk/lib/server/libjvm.debuginfo # level=1: 144M # level=2: 860M # level=3: 892M Since debuginfo-s are duplicated several times in our build dir, we are scratching against the 14G guaranteed free space on GHA runners, and reducing to level=1 buys us a lot of headroom: $ du -sh build/linux-x86_64-server-fastdebug/ # level=1: 4.0G # level=2: 14.0G # level=3: 16.0G Similar thing on MacOS AArch64 (Clang): % du -sh ./build/macosx-aarch64-server-fastdebug/images/jdk/lib/server/libjvm.dylib.dSYM/ # level=1: 92M # level=2: 202M # level=3: 202M % du -sh ./build/macosx-aarch64-server-fastdebug/ # level=1: 3.6G # level=2: 5.6G # level=3: 5.6G ------------- PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3713722791 PR Comment: https://git.openjdk.org/jdk/pull/29056#issuecomment-3714487776
