Bug 260187 - java/bootstrap-openjdk17: broken on aarch64
Summary: java/bootstrap-openjdk17: broken on aarch64
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: arm64 Any
: --- Affects Many People
Assignee: freebsd-java (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-03 11:55 UTC by Mikael Urankar
Modified: 2023-07-25 06:30 UTC (History)
8 users (show)

See Also:
bugzilla: maintainer-feedback? (java)


Attachments
git diff of java/openjdk17 (1.00 KB, patch)
2022-11-27 13:20 UTC, Ronald Klop
no flags Details | Diff
Compressed pointers patch (1.83 KB, patch)
2023-01-15 18:29 UTC, Greg Lewis
no flags Details | Diff
Little fix on patch of Greg Lewis (1.83 KB, patch)
2023-01-23 09:51 UTC, Ronald Klop
ronald: maintainer-approval? (java)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mikael Urankar freebsd_committer freebsd_triage 2021-12-03 11:55:27 UTC
/usr/local/bootstrap-openjdk17/bin/java
Error occurred during initialization of VM
Could not allocate compressed class space: 1073741824 bytes
Exit 1

Any ideas?
Comment 1 Greg Lewis freebsd_committer freebsd_triage 2021-12-07 02:25:44 UTC
Hmmm, I'm not sure what might be going wrong, but I can add details about the binary itself.

It was built on an AWS aarch64 instance.  I installed 12.2 and built the current version of the openjdk17 port.  I then deleted things that weren't needed for bootstrap, like src.zip, the manual pages, the examples, etc.

What version are you trying this on and how much memory does the machine have?
Comment 2 Mikael Urankar freebsd_committer freebsd_triage 2021-12-07 09:34:45 UTC
(In reply to Greg Lewis from comment #1)
It's on a recent 14-current, the board has 64gb of RAM.
Comment 3 Greg Lewis freebsd_committer freebsd_triage 2021-12-29 04:45:01 UTC
I tried this on both FreeBSD 12.3/arm64 and FreeBSD 13.0/arm64 and it worked on both of them.

The JDK sometimes encounters problems on -CURRENT.  These often end up being bugs in -CURRENT if they can't be reproduced on released versions.  In this case I would suggest transferring this to the Base System category unless FreeBSD 14 is planning to deliberately break compatibility with earlier releases.
Comment 4 Mikael Urankar freebsd_committer freebsd_triage 2022-01-19 11:54:02 UTC
Cannot reproduce with a recent 14-current, closing.
Comment 5 Mikael Urankar freebsd_committer freebsd_triage 2022-01-20 09:27:50 UTC
(In reply to Mikael Urankar from comment #4)
It happened again, setting kern.elf64.aslr.pie_enable=0 fixed it
Comment 6 Bjoern A. Zeeb freebsd_committer freebsd_triage 2022-05-15 23:30:06 UTC
I just hit this on my honeycomb machine trying to build openjdk17 on a CURRENT from two days ago or so...

...
checking bash version... 5.1.16
checking if bash supports pipefail... yes
checking if bash supports errexit (-e)... yes
checking pkg-config is at least version 0.9.0... yes
checking for default LOG value... 
checking if packaged modules are kept... enabled, default
checking for version string... 17.0.3+7-1
configure: Found potential Boot JDK using configure arguments
configure: Potential Boot JDK found at /usr/local/bootstrap-openjdk17 is not a working JDK; ignoring
configure: Output from java -version was: Error occurred during initialization of VM
Could not allocate compressed class space: 1073741824 bytes
configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK
configure exiting with result code 1
===>  Script "configure" failed unexpectedly.
Please report the problem to java@FreeBSD.org [maintainer] and attach the
"/var/tmp/work-20220515/usr/ports/java/openjdk17/work/jdk17u-jdk-17.0.3-7-1/config.log"
including the output of the failure of your make command. Also, it might be
a good idea to provide an overview of all packages installed on your system
(e.g. a /usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/java/openjdk17
*** Error code 1

And I can confirm that setting the sysctl fixed it here too:

# /usr/local/bootstrap-openjdk17/bin/jar --help
Error occurred during initialization of VM
Could not allocate compressed class space: 1073741824 bytes

# sysctl kern.elf64.aslr.pie_enable=0
kern.elf64.aslr.pie_enable: 1 -> 0
#  /usr/local/bootstrap-openjdk17/bin/jar --version
jar 17.0.1


Thanks a lot for leaving the fix.  I have no idea how the ports framework might handle this dynamically but if it can it probably should... at least give a warning/error without trying to build.
Comment 7 Ronald Klop 2022-05-16 07:49:26 UTC
See this thread for more info about the issue.
https://lists.freebsd.org/archives/freebsd-arm/2022-May/001340.html

It is pretty easy to workaround the failure of bootstrap-openjdk17 by using "ELF_FEATURES=  +noaslr:bin/*" in the port. See the linked mail for a more elaborate patch which only enables this on aarch64.
But using this to build the java/openjdk17 build still fails in all kinds of internal executables with that same error during the openjdk17 build.
I don't know how to workaround this in the ports framework.

Plus -more important- why does this only happen on aarch64 and not amd64?

I can reproduce this on an rpi4/8GB running:
# uname -a
FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #7 main-31e076d70b: Wed Mar 23 08:55:39 CET 2022     ronald@rpi4:/home/ronald/dev/obj/home/ronald/dev/freebsd/arm64.aarch64/sys/GENERIC-NODEBUG arm64

Although my build jail is newer than the host.
[00:00:01] Host OSVERSION: 1400053
[00:00:01] Jail OSVERSION: 1400055

I have no idea if something is broken in Java or in FreeBSD.
Comment 8 Bjoern A. Zeeb freebsd_committer freebsd_triage 2022-05-16 12:02:42 UTC
(In reply to Ronald Klop from comment #7)

Thanks for all the further information.

Having changed to the sysctl openjdk17 did build fine for me on arm64:
# /usr/local/openjdk17/bin/java --version
openjdk 17.0.3 2022-04-19
OpenJDK Runtime Environment (build 17.0.3+7-1)
OpenJDK 64-Bit Server VM (build 17.0.3+7-1, mixed mode, sharing)

Maybe we should just compile java with -fno-stack-protector (assuming that's the correct option) for the time being?
Comment 9 Ronald Klop 2022-05-16 13:58:59 UTC
These settings have something to do with it:

[root@rpi4 ~]# /usr/local/bootstrap-openjdk17/bin/java  -version
Error occurred during initialization of VM
Could not allocate compressed class space: 1073741824 bytes

[root@rpi4 ~]# /usr/local/bootstrap-openjdk17/bin/java -XX:CompressedClassSpaceSize=1m -version
Error occurred during initialization of VM
Could not allocate compressed class space: 4194304 bytes

[root@rpi4 ~]# /usr/local/bootstrap-openjdk17/bin/java -XX:CompressedClassSpaceSize=10g -version
size_t CompressedClassSpaceSize=10737418240 is outside the allowed range [ 1048576 ... 3221225472 ]
Improperly specified VM option 'CompressedClassSpaceSize=10g'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

No value of CompressedClassSpaceSize works. But disabling CompressedClassPointers does:

[root@rpi4 ~]# /usr/local/bootstrap-openjdk17/bin/java -XX:-UseCompressedClassPointers -version
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment (build 17.0.1+12-1)
OpenJDK 64-Bit Server VM (build 17.0.1+12-1, mixed mode)
Comment 10 Mikael Urankar freebsd_committer freebsd_triage 2022-05-19 08:15:24 UTC
reopen
Comment 11 John F. Carr 2022-08-12 13:48:48 UTC
I have this problem on 13.1-STABLE as well as CURRENT.

If I set kern.elf64.aslr.honor_sbrk=1 I can run the bootstrap-openjdk17 java at the command line, but it still fails with "Could not allocate compressed class space" when poudriere tries to build openjdk17.

In its current state the port should be marked broken on aarch64.
Comment 12 Ronald Klop freebsd_committer freebsd_triage 2022-11-27 13:20:43 UTC
Created attachment 238371 [details]
git diff of java/openjdk17

Using this patch I can build openjdk17 using the current bootstrap-openjdk17 and the resulting pkg can run java/javac/javap without additional cmdline parameters or sysctl settings.
The patch effectively makes "-XX:-UseCompressedClassPointers" the default.
Tested on rpi4 aarch64/14 in a 13.1 jail.
I see it as a workaround but at least it gives a working JDK 17.
Comment 13 Greg Lewis freebsd_committer freebsd_triage 2023-01-15 18:29:20 UTC
Created attachment 239493 [details]
Compressed pointers patch

I wondered if we might want to maintain the change as an extra patch rather than a sed command.  Like we do for the PPC specific changes.

If you've got time, can you take a look at the attached patch and give it a try to see if it works?
Comment 14 Ronald Klop freebsd_committer freebsd_triage 2023-01-23 09:51:43 UTC
Created attachment 239653 [details]
Little fix on patch of Greg Lewis

(In reply to Greg Lewis from comment #13)
Your patch didn't apply when running "make patch". I recreated the patch by "make makepatch".
Currently running a test build and will do a runtime test later today.
Comment 15 Ronald Klop freebsd_committer freebsd_triage 2023-01-23 12:36:58 UTC
Latest patch runs fine on 14/aarch64.

[root@rpi4 ~]# /usr/local/openjdk17/bin/java -XX:+PrintFlagsFinal -version | grep -i compr
   size_t CompressedClassSpaceSize                 = 1073741824                                {product} {default}
     bool UseCompressedClassPointers               = false                          {product lp64_product} {ergonomic}
     bool UseCompressedOops                        = true                           {product lp64_product} {ergonomic}
openjdk version "17.0.5" 2022-10-18
OpenJDK Runtime Environment (build 17.0.5+8-1)
OpenJDK 64-Bit Server VM (build 17.0.5+8-1, mixed mode, sharing)

[root@rpi4 ~]# uname -a
FreeBSD rpi4 14.0-CURRENT FreeBSD 14.0-CURRENT #3 main-f4d3aa7490: Thu Dec  1 22:38:06 CET 2022     ronald@rpi4:/home/ronald/dev/freebsd/obj/home/ronald/dev/freebsd/src/arm64.aarch64/sys/GENERIC-NODEBUG arm64
Comment 16 commit-hook freebsd_committer freebsd_triage 2023-01-24 05:19:48 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=b39d592147e2c549d009e01dba155f14128e600f

commit b39d592147e2c549d009e01dba155f14128e600f
Author:     Greg Lewis <glewis@FreeBSD.org>
AuthorDate: 2023-01-24 05:15:43 +0000
Commit:     Greg Lewis <glewis@FreeBSD.org>
CommitDate: 2023-01-24 05:19:21 +0000

    java/openjdk17: Fix the build on some aarch64 machines

    * Disable CompressedClassPointers on aarch64.  This fixes the build
      on some aarch64 machines where it previously failed, e.g. RPI4,
      and doesn't seem to affect the build on others (AWS aarch64 hardware).

    This is based on and uses a patch initially created by ronald@

    PR:             260187
    Tested by:      ronald@

 java/openjdk17/Makefile                             |  5 +++++
 ...ch-src_hotspot_share_runtime_arguments.cpp (new) | 21 +++++++++++++++++++++
 2 files changed, 26 insertions(+)
Comment 17 Ronald Klop freebsd_committer freebsd_triage 2023-07-10 15:18:45 UTC
Does this PR still have pending actions or can it be closed?
Comment 18 Dima Panov freebsd_committer freebsd_triage 2023-07-10 16:42:32 UTC
(In reply to Ronald Klop from comment #17)
It is still fails for any openjdk/aarch64 for vmware instance on apple m1/m2

configure: Output from java -version was: #
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x000000004a18ceec, pid=16643, tid=368704
#
# JRE version:  (17.0.1+12) (build )
# Java VM: OpenJDK 64-Bit Server VM (17.0.1+12-1, mixed mode, tiered, compressed oops, g1 gc, bsd-aarch64)
# Problematic frame:
# v  ~BufferBlob::native signature handlers
#
# Core dump will be written. Default location: /wrkdirs/usr/ports/java/openjdk17/work/jdk17u-jdk-17.0.7-7-1/java.core
#
# An error report file with more information is saved as:
# /wrkdirs/usr/ports/java/openjdk17/work/jdk17u-jdk-17.0.7-7-1/hs_err_pid16643.log
#
#
configure: error: The path given by --with-boot-jdk does not contain a valid Boot JDK
configure exiting with result code 1
Comment 19 Ronald Klop freebsd_committer freebsd_triage 2023-07-10 20:24:16 UTC
(In reply to Dima Panov from comment #18)
Ah. Interesting error. Although it is a different error than what this PR started with. Could you open a new PR for your error? Also because it seems specific to Apple M1/M2.
Comment 20 Dima Panov freebsd_committer freebsd_triage 2023-07-10 20:40:16 UTC
(In reply to Ronald Klop from comment #19)
Seems like related PR is already open
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265284
Comment 21 Greg Lewis freebsd_committer freebsd_triage 2023-07-25 02:43:21 UTC
I think this is a different problem than the Apple Silicon problem and should be closed.