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
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
