On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <[email protected]> wrote:

> The dead_strip linker option on macOS removes functions and data that are 
> unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for 
> example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

The was a bit of discussion on serviceability-dev  some years ago about that 
lto on libjvm issue and the serviceability errors and Magnus commented 

'We used to have LTO enabled on the old, closed-source Oracle arm-32 builds. 
There is still a "link-time-opt" JVM feature present; afaik it still works and 
adds the -flto flag. The main drawback of this is the *extremely* long link 
times of libjvm.so.
I don't think servicability was ever supported for that platform, so I'm not 
surprised this does not work. '

Probably the dead-strip feature runs into similar issues.

I commented back then 
'The  serviceability   tests like  serviceability/sa   seems to rely   heavily  
on the "normal"   structure  of   libjvm.so   (from what I   understand  e.g. 
in  LinuxVtblAccess  it is attempted to access  internal symbols  like  _ZTV ).'

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3547920976

Reply via email to