EA feedback
Calvin Cheung
calvin.cheung at oracle.com
Tue Aug 13 03:54:10 UTC 2024
Hi Danny,
On 8/9/24 1:38 PM, Danny Thomas wrote:
> I tried 24-leydenpremain+2-8 on a few internal applications, some
> quick feedback below (good to see you folks at the JVM LS!).
Thanks for trying the EA build.
>
> If a jar has a Class-Path attribute and one or more of those libraries
> are explicitly on the classpath, it causes the actual and expected
> classpath to always differ. This is also the case currently with CDS
> of course, but this feature is sure to be deployed far more broadly
> than CDS is currently, so likely something you want to look at:
>
> [0.057s][info][class,path] non-existent Class-Path entry
> lib/failureaccess-1.0.1.jar
> [0.057s][info][class,path] opened:
> lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
> [0.057s][info][class,path] library =
> lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar
I couldn't reproduce the above Class-Path attribute issue with a simple
test[1]. The simple test was extracted from an existing test case[2].
Can you provide a test case?
(I'll let others to answer the other issues.)
Thanks,
Calvin
[1] https://cr.openjdk.org/~ccheung/cp-attribute/
[2]
https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/ClassPathAttr.java
>
> Startup time when training seems to be on par
> with ArchiveClassesAtExit in JDK 21, but it's about a 3.5x startup
> time penalty for one of our typical Spring Boot applications. From a
> back-to-back run on my machine (AMD EPYC 9R14, 32 cores, 123G, Ubuntu
> 22.04.4 LTS):
>
> Started App in 7.698 seconds (process running for 8.229)
> Started App in 26.247 seconds (process running for 29.262) - w/
> CacheDataStore, Training Run
> Started App in 4.341 seconds (process running for 4.917) - w/
> CacheDataStore, Production Run
>
> I also got a crash on one attempt, I can't remember what I did to
> cause this unfortunately:
>
> Stack: [0x00007f3949ab0000,0x00007f3949bb0000],
> sp=0x00007f3949bae628, free space=1017k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> C=native code)
> V [libjvm.so+0x42ca30] ArchiveBuilder::get_buffered_addr(unsigned
> char*) const+0x40
> V [libjvm.so+0xce4aa5] VM_PopulateDumpSharedSpace::doit()+0x395
> V [libjvm.so+0x100ae69] VM_Operation::evaluate()+0x109
> V [libjvm.so+0x100e348] VMThread::evaluate_operation(VM_Operation*)+0xe8
> V [libjvm.so+0x10142fb] VMThread::inner_execute(VM_Operation*)+0x35b
> V [libjvm.so+0x101460f] VMThread::run()+0x16f
> V [libjvm.so+0xf6e5cf] Thread::call_run()+0x9f
> V [libjvm.so+0xd74e13] thread_native_entry(Thread*)+0x183
> C [libc.so.6+0x98b07]
>
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
> 0x0000000000000030
>
> Thinking ahead to operationalizing AOT, while a single-shot/on-exit
> workflow is great for iterating locally, requiring the VM to exit
> makes this more difficult to operationalize at scale:
>
> 1. We'll perform training and assembly on test, production canary and
> production instances on behalf of application owners and handle
> distribution of the archives. Depending on when we're able to
> perform a training run, it'll have different benefits. i.e.:
> 1. Test environment will at least improve startup performance,
> with a mixed benefit for warm up depending on the kind of
> traffic they take in test
> 2. If an application uses canary deployments we'll have a full
> production profile prior to the full production deployment,
> and all instances will come up hot
> 3. If we reach production with only a test environment profile,
> we'll perform a training run in production, so instances that
> scale up following that run will come up hot (completely cold
> instances for an initial deployment is less of a concern,
> because we deploy immutably and get a natural warm-up period
> while we have 200% capacity online for a cluster)
> 2. It's currently not a problem if a VM doesn't exit completely due
> to a dangling non-daemon thread or hung shutdown hook
>
> Being able to trigger assembly/verification via jcmd without
> exiting, would make this far easier for us to support. If the overhead
> of the instrumentation for CDS can be avoided, being able to take a
> snapshot at any time on any VM would be better still, but that
> wouldn't be an impediment for us: we'll know that the instance will be
> used for training at boot time.
>
> We build nightlies of all the currently active OpenJDK projects, so if
> you land anything on premain between EA builds that you'd like us to
> try, let us know!
>
> Cheers,
> Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240812/d52b1a57/attachment.htm>
More information about the leyden-dev
mailing list