Hi debian-java maintainers,

Last year, I implemented the fast bytecodes feature in OpenJDK Zero interpreter [1]. It shipped with
JDK 18, and I have recently backported it to 17u. This should land in 17.0.7 in April 2023.

I believe Debian runs with Zero on some architectures that do not have "server" ports. From the look
at openjdk-17-jdk [2], I assume at least alpha, mips64el, mipsel, riscv64, sparc64, m68k, sh4 are
running with Zero.

This feature should make the builds that involve OpenJDK -- for example, building Java packages --
considerably faster. On my RISC-V board, the 17u tests are routinely >10% faster, some tests are 50%
faster.

But there might be new bugs, so I wanted to give you a heads-up about this. -XX:-RewriteBytecodes
restores the original behavior, if needed. If there are even more serious problems, we can revert
the backport completely. It would be nice to know about this before the 17.0.7 release crunch in
late March, though.

Is there an easy way to check if e.g. bookworm can be fully re-built with latest and greatest 17.0.7
EA?

--
Thanks,
-Aleksey

[1] https://bugs.openjdk.org/browse/JDK-8008243
[2] https://packages.debian.org/search?keywords=openjdk-17-jdk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Aleksey,

Le 05/01/2023 à 10:16, Aleksey Shipilev a écrit :

Last year, I implemented the fast bytecodes feature in OpenJDK Zero interpreter [1]. It shipped with JDK 18, and I have recently backported
it to 17u. This should land in 17.0.7 in April 2023.

I believe Debian runs with Zero on some architectures that do not have "server" ports. From the look at openjdk-17-jdk [2], I assume at least
alpha, mips64el, mipsel, riscv64, sparc64, m68k, sh4 are running with Zero.

This feature should make the builds that involve OpenJDK -- for example, building Java packages -- considerably faster. On my RISC-V board, the
17u tests are routinely >10% faster, some tests are 50% faster.

This looks promising, thank you!

Is it enabled in all JDKs after JDK 18 too?

But there might be new bugs, so I wanted to give you a heads-up about
this. -XX:-RewriteBytecodes restores the original behavior, if needed.
If there are even more serious problems, we can revert the backport completely. It would be nice to know about this before the 17.0.7
release crunch in late March, though.

Is there an easy way to check if e.g. bookworm can be fully re-built
with latest and greatest 17.0.7 EA?

Its tricky, the arch all packages are usually built and tested on amd64
only (reproducible-builds.org also rebuilds on i386, arm64 and armhf). Rebuilding the 1500+ Java packages takes at least two days on a 4c/8t
4GHz Xeon, but on m68k it's going to take ages and that would abuse a
bit the shared porter boxes.

Technically, this implies:
- logging into a porter box (https://db.debian.org/machines.cgi)
- cloning the java-common and openjdk-17 packages (using debcheckout)
- rebuilding these two packages
- running ratt (https://tracker.debian.org/pkg/ratt) with the .changes
files of java-common and openjdk-17
- relax and grab some popcorn
- cry because you forgot to use 'screen'
- analyze the build logs, looking for unexpected failures compared to
amd64 (reproducible-builds.org [1] has a good summary of the know build
issues)

Emmanuel Bourg

[1] https://tests.reproducible-builds.org/debian/unstable/amd64/pkg_set_maint_pkg-java-maintainers.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Emmanuel,

On 1/5/23 23:20, Emmanuel Bourg wrote:

Is it enabled in all JDKs after JDK 18 too?

Yes, it is implemented and enabled by default in JDK 18+ onward. I now see openjdk-{18,19,20,21}-*
ship in sid for many architectures already, so this Zero improvement might already be implicitly tested.

Is there an easy way to check if e.g. bookworm can be fully re-built
with latest and greatest 17.0.7 EA?

Its tricky, the arch all packages are usually built and tested on amd64
only (reproducible-builds.org also rebuilds on i386, arm64 and armhf). Rebuilding the 1500+ Java packages takes at least two days on a 4c/8t
4GHz Xeon, but on m68k it's going to take ages and that would abuse a
bit the shared porter boxes.

Yes, m68k (linker?) is problematic even for vanilla OpenJDK cross-builds.

Since openjdk 18+ packages are already built, which I assume implies that someone would eventually
rebuild/run the Java packages with them, I would just wait for bug reports then. If that happens,
tell me if you need a debian-specific patch to disable/yank the change from any openjdk tree.

--
Thanks,
-Aleksey

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)