Re: How do I reliably prevent CDS archive generation during builds?
Thank you, Eric! On Mon, May 6, 2024 at 7:21 PM wrote: > On 5/6/24 09:26, Thomas Stüfe wrote: > > Hi, > > > > is there a way to reliably prevent the jvm from being called with > > -Xshare:dump during build? > > > > Often, when I tinker with metaspace or compressed klass pointers, CDS > > gets broken. During development, that is fine; it is a temporary state. > > > > However, if -Xshare:dump is invoked, it may crash the JVM and break > > the build. > > > > I specified --disable-cds-archives and > > --disable-jvm-feature-link-time-opt. But still, link time optimization > > step runs and calls the build JVM with -Xshare:dump. Is that a bug? > > > I think if you add --disable-generate-classlist to that list of > configure arguments, this particular invocation with -Xshare:dump will > go away. > > /Erik > > > Thanks, Thomas > > > > P.S. Also, how is this handled for crossbuilds, where generating > > shared archives on the build machine makes little sense? > > > > > > >
Re: How do I reliably prevent CDS archive generation during builds?
Hi Julian, Yes, that confused me too. See here: https://github.com/openjdk/jdk/blob/f308e107ce8b993641ee3d0a0d5d52bf5cd3b94e/make/GenerateLinkOptData.gmk#L76 Cheers, Thomas On Tue, May 7, 2024 at 2:58 AM Julian Waters wrote: > Hi Thomas, > > --disable-jvm-feature-link-time-opt is for disabling Link Time > Optimization when compiling the JVM itself, as in, requesting LTO from > the linker that is linking the JVM. It doesn't have anything to do > with what arguments the newly compiled JVM is called with and isn't > related to the link optimization pass of the Java classfiles (I am not > very familiar with that process), and it is also off by default for > most platforms > > best regards, > Julian >
Re: Hermetic Java project meeting
On Tue, Apr 30, 2024 at 5:42 AM Magnus Ihse Bursie wrote: > > > On 2024-04-26 03:15, Jiangli Zhou wrote: > > On Thu, Apr 25, 2024 at 9:28 AM Magnus Ihse Bursie > > wrote: > >> > >> Just to be more clear, that's with using `objcopy` to localize > >> non-exported symbols for all JDK static libraries and libjvm.a, not just > >> libjvm.a right? > >> > >> Yes. > >> > >> > >> Can you please include the compiler or linker errors on linux/clang? > >> > >> It is a bit tricky. The problem arises at the partial linking step. The > >> problem seem to arise out of how clang converts a request to link into an > >> actual call to ld. I enabled debug code (printing the command line, and > >> running clang with `-v` to get it to print the actual command line used to > >> run ld) and ran it on GHA, where it worked fine. This is how it looks > >> there: > >> > >> WILL_RUN: /usr/bin/clang -v -m64 -r -o > >> /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/librmi_relocatable.o > >> > >> /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/GC.o > >> Ubuntu clang version 14.0.0-1ubuntu1.1 > >> Target: x86_64-pc-linux-gnu > >> Thread model: posix > >> InstalledDir: /usr/bin > >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/10 > >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/11 > >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/12 > >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13 > >> Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/9 > >> Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13 > >> Candidate multilib: .;@m64 > >> Selected multilib: .;@m64 > >> "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m > >> elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o > >> /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/librmi_relocatable.o > >> -L/usr/bin/../lib/gcc/x86_64-linux-gnu/13 > >> -L/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../lib64 > >> -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu > >> -L/usr/lib/../lib64 -L/usr/lib/llvm-14/bin/../lib -L/lib -L/usr/lib -r > >> /home/runner/work/jdk/jdk/build/linux-x64/support/native/java.rmi/librmi/static/GC.o > >> > >> In contrast, on my machine it looks like this: > >> > >> WILL_RUN: > >> /usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin/clang -v > >> -m64 -r -o > >> /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/librmi_relocatable.o > >> > >> /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/GC.o > >> clang version 13.0.1 > >> Target: x86_64-unknown-linux-gnu > >> Thread model: posix > >> InstalledDir: > >> /usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin > >> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 > >> Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9 > >> Candidate multilib: .;@m64 > >> Candidate multilib: 32;@m32 > >> Candidate multilib: x32;@mx32 > >> Selected multilib: .;@m64 > >> "/usr/bin/ld" --hash-style=both --eh-frame-hdr -m elf_x86_64 > >> -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o > >> /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/librmi_relocatable.o > >> /lib/x86_64-linux-gnu/crt1.o /lib/x86_64-linux-gnu/crti.o > >> /usr/lib/gcc/x86_64-linux-gnu/9/crtbegin.o > >> -L/usr/lib/gcc/x86_64-linux-gnu/9 > >> -L/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib64 > >> -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu > >> -L/usr/lib/../lib64 > >> -L/usr/local/clang+llvm-13.0.1-x86_64-linux-gnu-ubuntu-18.04/bin/../lib > >> -L/lib -L/usr/lib -r > >> /localhome/git/jdk-ALT/build/clangherm/support/native/java.rmi/librmi/static/GC.o > >> -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s > >> --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/9/crtend.o > >> /lib/x86_64-linux-gnu/crtn.o > >> /usr/bin/ld: cannot find -lgcc_s > >> /usr/bin/ld: cannot find -lgcc_s > >> clang-13: error: linker command failed with exit code 1 (use -v to see > >> invocation) > >> > >> I don't understand what makes clang think it should include "-lgcc > >> --as-needed -lgcc_s" and the crt*.o files when doing a partial link. In > >> fact, the entire process on how clang (and gcc) builds up the linker > >> command line is bordering on black magic to me. I think it can be affected > >> by variables set at compile time (at least this was the case for gcc, last > >> I checked), or maybe it picks up some kind of script from the environment. > >> That's why I believe my machine could just be messed up. > >> > >> I could get a bit further by passing "-nodefaultlibs" (or whatever it > >> was), but then the generated .o file were messed up wrt to library symbols > >> and it failed dramatically when trying to d
How do I reliably prevent CDS archive generation during builds?
Hi Thomas, --disable-jvm-feature-link-time-opt is for disabling Link Time Optimization when compiling the JVM itself, as in, requesting LTO from the linker that is linking the JVM. It doesn't have anything to do with what arguments the newly compiled JVM is called with and isn't related to the link optimization pass of the Java classfiles (I am not very familiar with that process), and it is also off by default for most platforms best regards, Julian
Re: RFR: 8329538: Accelerate P256 on x86_64 using Montgomery intrinsic [v6]
> Performance. Before: > > Benchmark(algorithm) (dataSize) (keyLength) > (provider) Mode Cnt ScoreError Units > SignatureBench.ECDSA.signSHA256withECDSA1024 256 > thrpt3 6443.934 ± 6.491 ops/s > SignatureBench.ECDSA.signSHA256withECDSA 16384 256 > thrpt3 6152.979 ± 4.954 ops/s > SignatureBench.ECDSA.verify SHA256withECDSA1024 256 > thrpt3 1895.410 ± 36.979 ops/s > SignatureBench.ECDSA.verify SHA256withECDSA 16384 256 > thrpt3 1878.955 ± 45.487 ops/s > Benchmark(algorithm) (keyLength) > (kpgAlgorithm) (provider) Mode Cnt ScoreError Units > o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret ECDH 256 > EC thrpt3 1357.810 ± 26.584 ops/s > o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret ECDH 256 > EC thrpt3 1352.119 ± 23.547 ops/s > Benchmark (isMontBench) Mode Cnt Score > Error Units > PolynomialP256Bench.benchMultiply false thrpt3 1746.126 ± > 10.970 ops/s > > Performance, no intrinsic: > > Benchmark(algorithm) (dataSize) (keyLength) > (provider) Mode Cnt Score Error Units > SignatureBench.ECDSA.signSHA256withECDSA1024 256 > thrpt3 6529.839 ± 42.420 ops/s > SignatureBench.ECDSA.signSHA256withECDSA 16384 256 > thrpt3 6199.747 ± 133.566 ops/s > SignatureBench.ECDSA.verify SHA256withECDSA1024 256 > thrpt3 1973.676 ± 54.071 ops/s > SignatureBench.ECDSA.verify SHA256withECDSA 16384 256 > thrpt3 1932.127 ± 35.920 ops/s > Benchmark(algorithm) (keyLength) > (kpgAlgorithm) (provider) Mode Cnt ScoreError Units > o.o.b.j.c.full.KeyAgreementBench.EC.generateSecret ECDH 256 > EC thrpt3 1355.788 ± 29.858 ops/s > o.o.b.j.c.small.KeyAgreementBench.EC.generateSecret ECDH 256 > EC thrpt3 1346.523 ± 28.722 ops/s > Benchmark (isMontBench) Mode Cnt Score > Error Units > PolynomialP256Bench.benchMultiply true thrpt3 1919.574 ± > 10.591 ops/s > > Performance, **with intrinsics*... Volodymyr Paprotski has updated the pull request incrementally with one additional commit since the last revision: Use AffinePoint to exit Montgomery domain Style notes: Affine.equals() - Mismatched fields only appear to be used from testing, perhaps should be moved there instead Affine.getX(boolean)|getY(boolean) - "Passing flag is bad design" - cleanest/performant alternative to several instanceof checks - needed to convert Affine to Projective (need to stay in montgomery domain) ECOperations.PointMultiplier - changes could probably be restored to original (since ProjectivePoint handling no longer required) - consider these changes an improvement? (fewer nested classes) - was an inner-class but not using inner-class features (i.e. ecOps variable should be converted) - Changes: - all: https://git.openjdk.org/jdk/pull/18583/files - new: https://git.openjdk.org/jdk/pull/18583/files/a1984501..8ff243a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18583&range=04-05 Stats: 268 lines in 7 files changed: 89 ins; 147 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/18583.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18583/head:pull/18583 PR: https://git.openjdk.org/jdk/pull/18583
Re: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments [v66]
> Please review a patch to add support for Markdown syntax in documentation > comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` > library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Remove `--no-fonts` from `MISSING_IN_MAN_PAGE` - Changes: - all: https://git.openjdk.org/jdk/pull/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/9ad5c398..e48ebb53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=65 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=64-65 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388
undefined symbols in libjvm.so
Hi, I have recently encountered bugs caused by undefined symbols in libjvm.so[1][2]. The root cause of those issues is the expression in make/autoconf/flags-ldflags.m4: --- if test "x$TOOLCHAIN_TYPE" = xgcc; then EXECUTABLE_LDFLAGS="$EXECUTABLE_LDFLAGS -Wl,--allow-shlib-undefined" ... -- OpenJDK master builds fine after fixing[1] on the following architectures: amd64, i386, armhf, arm64, s390, ppc64el and riscv64. Would it be possible to consider removing -Wl,--allow-shlib-undefined from the build flags? Best Regards, Vladimir. [1] https://bugs.openjdk.org/browse/JDK-8331541 [2] https://bugs.openjdk.org/browse/JDK-8329983
Re: RFR: 8298405: Implement JEP 467: Markdown Documentation Comments [v65]
> Please review a patch to add support for Markdown syntax in documentation > comments, as described in the associated JEP. > > Notable features: > > * support for `///` documentation comments in `JavaTokenizer` > * new module `jdk.internal.md` -- a private copy of the `commonmark-java` > library > * updates to `DocCommentParser` to treat `///` comments as Markdown > * updates to the standard doclet to render Markdown comments in HTML Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Update javadoc.1 troff man page - Changes: - all: https://git.openjdk.org/jdk/pull/16388/files - new: https://git.openjdk.org/jdk/pull/16388/files/e42632a9..9ad5c398 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=64 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16388&range=63-64 Stats: 23 lines in 1 file changed: 10 ins; 3 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/16388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16388/head:pull/16388 PR: https://git.openjdk.org/jdk/pull/16388
Re: How do I reliably prevent CDS archive generation during builds?
On 5/6/24 09:26, Thomas Stüfe wrote: Hi, is there a way to reliably prevent the jvm from being called with -Xshare:dump during build? Often, when I tinker with metaspace or compressed klass pointers, CDS gets broken. During development, that is fine; it is a temporary state. However, if -Xshare:dump is invoked, it may crash the JVM and break the build. I specified --disable-cds-archives and --disable-jvm-feature-link-time-opt. But still, link time optimization step runs and calls the build JVM with -Xshare:dump. Is that a bug? I think if you add --disable-generate-classlist to that list of configure arguments, this particular invocation with -Xshare:dump will go away. /Erik Thanks, Thomas P.S. Also, how is this handled for crossbuilds, where generating shared archives on the build machine makes little sense?
How do I reliably prevent CDS archive generation during builds?
Hi, is there a way to reliably prevent the jvm from being called with -Xshare:dump during build? Often, when I tinker with metaspace or compressed klass pointers, CDS gets broken. During development, that is fine; it is a temporary state. However, if -Xshare:dump is invoked, it may crash the JVM and break the build. I specified --disable-cds-archives and --disable-jvm-feature-link-time-opt. But still, link time optimization step runs and calls the build JVM with -Xshare:dump. Is that a bug? Thanks, Thomas P.S. Also, how is this handled for crossbuilds, where generating shared archives on the build machine makes little sense?
Re: JDK-8170635
Not sure if you meant to address this mail to a specific person. I assume with proposal you mean this: https://mail.openjdk.org/pipermail/build-dev/2016-September/017746.html ? If yes, my proposal was to move dladdr out of the OpenJDK code base into an independent library that would be maintained by IBM, hopefully, and would be a prerequisite for building the JDK. If no, whose proposal did you mean? On Mon, May 6, 2024 at 11:58 AM Suchismith Roy wrote: > I wanted to discuss regarding https://bugs.openjdk.org/browse/JDK-8170635. > > Do you have any pointers on moving dladdr() for AIX according to the > current JDK23 structure. > I think you had suggested one proposition according to JDK11 ? > Could we get some more pointers on this proposition ? > > >
JDK-8170635
I wanted to discuss regarding https://bugs.openjdk.org/browse/JDK-8170635. Do you have any pointers on moving dladdr() for AIX according to the current JDK23 structure. I think you had suggested one proposition according to JDK11 ? Could we get some more pointers on this proposition ?
