RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size

[Chris Plummer]

On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken <mbaesken at openjdk.org> 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

Sorry, I think I went somewhat astray in my comments above. I think `classLoaderKlassField` is being initialized. It's value (an address) is then passed to instantiateWrapperFor():

  public static InstanceKlass getClassLoaderKlass() {
    return (InstanceKlass)Metadata.instantiateWrapperFor(classLoaderKlassField.getValue());
  }

instantiateWrapperFor() is failing. If you look at the stack trace (and the accompanying code), it appears that it has failed to lookup the base type, which is Metadata. There probably are no instances of Metadata allocated, just instances of subclasses, so possibly the Metadata vtbl has been dead stripped, and SA needs it. However, I would think this would result in mass failures since we call Metadata.instantiateWrapperFor() all over the place.

If you want to attempt a fix, have hotspot allocate a Metadata instance somewhere and keep a reference to it. That should prevent the Metadata vtbl from being dead stripped.

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

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