Details
- Reviewers
glewis bofh haraldei_anduin.net
Diff Detail
- Repository
- R11 FreeBSD ports repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 61362 Build 58246: arc lint + arc unit
Event Timeline
@glewis, was there some issue preventing us from stripping the shared libraries and binaries? I did some very basic runtime tests on 13amd64 and a recent main (also amd64).
root@13amd64-default:/usr/ports/java/openjdk23 # /usr/local/openjdk23/bin/java --version openjdk 23.0.1 2024-10-15 OpenJDK Runtime Environment (build 23.0.1+11-1) OpenJDK 64-Bit Server VM (build 23.0.1+11-1, mixed mode, sharing) root@13amd64-default:/usr/ports/java/openjdk23 # file /usr/local/openjdk23/bin/java /usr/local/openjdk23/bin/java: ELF 64-bit LSB pie executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 13.3, FreeBSD-style, stripped
I think this should be ok. There are some parts of the handling of internal errors that tries to look up debug info to get better stacktraces, but I don't think that is important to production deployments.
It depends, sometimes you simply cannot reproduce on non-prod. Does this affect jstack? This is often requested on the Tomcat mailing lists.
I think so, but only native code. The stack traces should still include all the information that the JVM itself handles.
Very good, there is likely only case: JVM crashes and dump file does contain any reasonable information for a backtrace.
I'll try to do some tests, so we can make a more informed decision about this :)
Perhaps good to hold off this change until then.
@michaelo I don't see any significant change between the output from jstack regardless of the target process running from stripped or non-stripped binaries: https://gist.github.com/snake66/319cdc0772902037610da906c0863d47
On the other hand, the openjdk build does run strip --strip-debug during the build, so not sure how much more value the extra strip run provides.
The main goal of this review is to understand why we aren't stripping binaries/libraries as usual. Of course, if we determine it's not beneficial, we can abandon this. That said, the stripping here (which I now see doesn't capture the largest libraries in places like ${STAGEDIR}${INSTALLDIR}/lib/server/) does have an effect.
Without this patch:
# ls -lah /usr/local/openjdk23/lib/libawt.so -rw-r--r-- 1 root wheel 750K Jan 13 16:26 libawt.so # file /usr/local/openjdk23/lib/libawt.so /usr/local/openjdk23/lib/libawt.so: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, for FreeBSD 15.0 (1500021), with debug_info, not stripped
With this patch:
# ls -lah /usr/local/openjdk23/lib/libawt.so -rw-r--r-- 1 root wheel 689K Jan 13 16:39 /usr/local/openjdk23/lib/libawt.so # file /usr/local/openjdk23/lib/libawt.so /usr/local/openjdk23/lib/libawt.so: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, for FreeBSD 15.0 (1500021), stripped
@jrm Yeah, I was mostly thinking about the quality of production code backtraces :) A full strip will clearly strip more than just debug info. It will probably make a difference for internal errors in the JVM itself, but not much for code running _on_ the JVM.
Correct and that is what I am a bit afraid of. Saving 70 kB compared to lack of information is ignorable unless you guys say not stripped binaries affect performance severely. FWIW, almost all Java code on Maven Central contains debug information like line numbers, etc. because it makes stracktracing much much easier. We, the Maven team, do recommend to retain debug info in Java code to make postmortem analysis easier.
I agree saving 70kB is not worth any reduction in debugability. It might be worth adding a # We don't strip in order to preserve debugability