Fwd: AOTCache + ZGC crashes
ioi.lam at oracle.com
ioi.lam at oracle.com
Thu Mar 27 18:36:45 UTC 2025
Hi Suresh,
Does this problem happen only with docker, and not with running directly
on a Linux host?
Could you send the exact command-lines that shows the error?
Thanks
- Ioi
On 3/25/25 4:51 PM, Suresh G wrote:
> Hi Loi,
>
> > We have decided to defer it and focus on delivering optimizations
> for the most common use cases first
> Thanks, make sense.
>
> > file format that's tied to the execution platform of the JVM
>
> The second issue I reported seems a bit different. While the Docker
> engine successfully downloads ARM64 JDK images and the AOT cache
> configuration is created, the error occurs when generating the cache
> using that same configuration in the exact same environment. This
> makes me wonder if the AOT cache generation process isn't properly
> recognizing the hardware architecture provided by the container
> platform where the configuration file was created.
>
> # AOT conf is created succesfully
> /opt/java/openjdk/bin/java --show-version --enable-preview
> -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders
> -XX:AOTMode=record -XX:AOTConfiguration=/app/app.aotconf -jar app.jar
> #39 63.57 openjdk 25-ea 2025-09-16
> #39 63.57 OpenJDK Runtime Environment (build 25-ea+15-1670)
> #39 63.57 OpenJDK 64-Bit Server VM (build 25-ea+15-1670, mixed mode)
> #39 64.30 Starting Http Server on port 80
> #39 66.43 + AOT training run completed!
>
>
> # But using the same JVM (execution env), creating AOT archive failed.
> #39 67.49 + /opt/java/openjdk/bin/java --show-version --enable-preview
> -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders
> -XX:AOTMode=create -XX:AOTConfiguration=/app/app.aotconf
> -XX:AOTCache=/app/app.aot -jar app.jar
> #39 67.67 Error occurred during initialization of VM
> #39 67.67 Must be a valid AOT configuration generated by the current
> JVM: /app/app.aotconf
>
> So IIUC, this is not really a cross platform AOT cache creation. More
> like cross platform docker run.
>
> Thanks
> Suresh
>
>
> On Mon, Mar 24, 2025 at 9:03 PM <ioi.lam at oracle.com> wrote:
>
> Hi Suresh,
>
> Thanks for the bug report. I have created
> https://bugs.openjdk.org/browse/JDK-8352775 to track this issue.
>
> This issue is new in JDK 25 EA and does not affect JDK 24.
>
> Please see my comments below
>
>
> On 3/21/25 9:51 PM, Suresh G wrote:
>> Hello Leyden Team,
>>
>> I'm currently testing the new AOT cache feature with the latest
>> OpenJDK 25 EA builds. My setup is straightforward, aiming to
>> create a Docker image with the AOT cache, much like I did
>> previously with AppCDS.
>>
>> Here is the docker multi-stage build for my sample Hello world app
>>
>> - Using openjdk:25-slim (25-ea+15-1670)
>> - Compiling and creating app.jar
>> - Getting module deps
>> jdeps -q \
>> -R \
>> --ignore-missing-deps \
>> --print-module-deps \
>> --multi-release=25 \
>> *.jar > ${APP_DIR}/java.modules
>>
>> - Creating jlinked image
>> $JAVA_HOME/bin/jlink \
>> --verbose \
>> --module-path ${JAVA_HOME}/jmods \
>> --add-modules="$(cat ${APP_DIR}/java.modules)" \
>> --compress=zip-9 \
>> --strip-debug \
>> --strip-java-debug-attributes \
>> --no-man-pages \
>> --no-header-files \
>> --save-opts "${APP_DIR}/jlink.opts" \
>> --output ${RUNTIME_IMAGE}
>>
>> - Creating AOT cache
>> echo "AOT training run for the app..."
>> nohup ${RUNTIME_IMAGE}/bin/java \
>> --show-version \
>> --enable-preview \
>> -XX:+UnlockExperimentalVMOptions \
>> -XX:+UseCompactObjectHeaders \
>> -XX:AOTMode=record
>> -XX:AOTConfiguration=${APP_DIR}/app.aotconf \
>> -jar ${APP_JAR} & \
>>
>> sleep 1 && \
>> curl -fsSL --retry 5 --retry-delay 2 --retry-all-errors
>> http://localhost/test
>> <https://urldefense.com/v3/__http://localhost/test__;!!ACWV5N9M2RV99hQ!KXT24eTgMOYWJzZaxvLdL8AVz5BjbfolvvweXuaVgurQTgEI7CMnqkQO4FgPpmqyH5WNvJIY6pr4Z3WP$>
>> curl -fsSL http://localhost/shutdown
>> <https://urldefense.com/v3/__http://localhost/shutdown__;!!ACWV5N9M2RV99hQ!KXT24eTgMOYWJzZaxvLdL8AVz5BjbfolvvweXuaVgurQTgEI7CMnqkQO4FgPpmqyH5WNvJIY6v7lLKPm$>
>> || echo "AOT training run completed!"
>>
>> echo "Creating AOT archive..."
>> ${RUNTIME_IMAGE}/bin/java \
>> --show-version \
>> --enable-preview \
>> -XX:+UnlockExperimentalVMOptions \
>> -XX:+UseCompactObjectHeaders \
>> -XX:AOTMode=create
>> -XX:AOTConfiguration=${APP_DIR}/app.aotconf
>> -XX:AOTCache=${APP_DIR}/app.aot \
>> -jar ${APP_JAR}
>>
>> - Now copy the APP_DIR to a distroless container (Final image)
>> ------------------------------------------------------------------------------------
>>
>> I'm experiencing the following issues with the current build.
>>
>> 1. JVM crashes with ZGC enabled:
>> #
>> # A fatal error has been detected by the Java Runtime
>> Environment:
>> #
>> # SIGSEGV (0xb) at pc=0x0000000105b4f318, pid=13825, tid=8963
>> #
>> # JRE version: (25.0+15) (build )
>> # Java VM: OpenJDK 64-Bit Server VM (25-ea+15-1670,
>> interpreted mode, sharing, compressed class ptrs, z gc, bsd-aarch64)
>> # Problematic frame:
>> # V [libjvm.dylib+0x47f318]
>> MetaspaceObjToOopHandleTable::set_oop(MetaspaceObj*, oopDesc*)+0x78
>> #
>> # No core dump will be written. Core dumps have been
>> disabled. To enable core dumping, try "ulimit -c unlimited"
>> before starting Java again
>> #
>> #
>>
>> --------------- S U M M A R Y ------------
>>
>> Command Line: --enable-preview
>> -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders
>> -XX:+UseZGC -XX:AOTMode=create -XX: AOTConfiguration=app.aotconf
>> -XX:AOTCache=app.aot app.jar
>>
>> Host: "MacBookPro18,1" arm64, 10 cores, 32G, Darwin 23.6.0,
>> macOS 14.6.1 (23G93)
>> Time: Fri Mar 21 20:21:47 2025 PDT elapsed time: 0.044457
>> seconds (0d 0h 0m 0s)
>>
>> --------------- T H R E A D ---------------
>>
>> Current thread (0x0000000136808c00): JavaThread "Unknown
>> thread" [_thread_in_vm, id=8963, stack(0x000000016bd84000,
>> 0x000000016bf87000) (2060K)]
>>
>> Stack: [0x000000016bd84000,0x000000016bf87000],
>> sp=0x000000016bf86380, free space=2056k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM
>> code, C=native code)
>> V [libjvm.dylib+0x47f318]
>> MetaspaceObjToOopHandleTable::set_oop(MetaspaceObj*, oopDesc*)+0x78
>> V [libjvm.dylib+0x2d1b38]
>> ConstantPool::restore_unshareable_info(JavaThread*)+0x20c
>> V [libjvm.dylib+0xa52928]
>> vmClasses::resolve_all(JavaThread*)+0xe0
>> V [libjvm.dylib+0x9a85cc]
>> SystemDictionary::initialize(JavaThread*)+0xa0
>> V [libjvm.dylib+0xa0c8d0] Universe::genesis(JavaThread*)+0x74
>> V [libjvm.dylib+0xa0f570] universe2_init()+0x24
>> V [libjvm.dylib+0x497dac] init_globals2()+0xc
>>
>> 2. AOT Cache generation fails during Docker cross-compilation:
>> Specifically, running docker build with --platform=linux/amd64on
>> ARM64 runner.
>>
>> 36.70 + /opt/java/openjdk/bin/java --enable-preview
>> -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders
>> -XX:AOTMode=create -XX:AOTConfiguration=/app/app.aotconf
>> -XX:AOTCache=/app/app.aot -jar app.jar
>> 36.70 Creating AOT archive...
>> 36.77 Error occurred during initialization of VM
>> 36.77 Must be a valid AOT configuration generated by the
>> current JVM: /app/app.aotconf
>>
>>
>> 3. Also, are there plans to make the app.aotconf file
>> cross-platform compatible? This would allow us to generate the
>> configuration once, and then produce platform-specific caches
>> from that configuration in CI systems like GitHub Actions.
>>
>>
> In JDK 25 and going forward, we are collecting execution profile
> during AOT training. As a result, we have changed the AOT
> configuration file to a binary file format that's tied to the
> execution platform of the JVM. You can see more information from
> https://bugs.openjdk.org/browse/JDK-8348426
>
> The profile data is difficult to be represented in a
> cross-platform format (e.g., a text file). The need for "cross
> platform builds" has come up before in our design discussion. We
> have decided to defer it and focus on delivering optimizations for
> the most common use cases first. We might re-evaluate this
> decision in the future when we have more user feedback (and more
> time :-)
>
> Thanks
>
> - Ioi
>
>
>> Thanks
>> Suresh
>
>
>
> --
> ~Suresh G
> <https://urldefense.com/v3/__http://www.google.com/profiles/sureshg.g__;!!ACWV5N9M2RV99hQ!KXT24eTgMOYWJzZaxvLdL8AVz5BjbfolvvweXuaVgurQTgEI7CMnqkQO4FgPpmqyH5WNvJIY6nMdJKfp$>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20250327/bbe2842e/attachment.htm>
More information about the leyden-dev
mailing list