AppCDS, DynamicCDS, Leyden and JRuby

[Charles Oliver Nutter]

On Wed, Feb 12, 2025 at 3:42 PM <ioi.lam at oracle.com> wrote:

> Hi Charlie,
>
> Thanks for trying CDS out. Is there any performance numbers you can share
> with us?
>
Sure! Here's a few JRuby command lines before and after with JDK 21 CDS:

Hello world, with and without --dev flag (--dev limits to tier 1, disables
JRuby JIT):

jruby -e 1  2.52s user 0.13s system 183% cpu 1.447 total
jruby --dev -e 1  1.16s user 0.12s system 125% cpu 1.014 total

With CDS:

jruby -e 1  1.78s user 0.10s system 192% cpu 0.979 total
jruby --dev -e 1  0.92s user 0.09s system 120% cpu 0.834 total

List all installed libraries (gems):

jruby -S gem list > /dev/null  5.24s user 0.23s system 215% cpu 2.532 total
jruby --dev -S gem list > /dev/null  2.15s user 0.21s system 112% cpu 2.089
total

With CDS:

jruby -S gem list > /dev/null  4.39s user 0.20s system 225% cpu 2.036 total
jruby --dev -S gem list > /dev/null  1.76s user 0.13s system 131% cpu 1.437
total

List all build targets in current project (rake):

jruby -S rake -T > /dev/null  4.58s user 0.25s system 143% cpu 3.363 total
jruby --dev -S rake -T > /dev/null  1.99s user 0.20s system 81% cpu 2.682
total

With CDS:

jruby -S rake -T > /dev/null  3.97s user 0.23s system 141% cpu 2.977 total
jruby --dev -S rake -T > /dev/null  1.77s user 0.18s system 78% cpu 2.476
total

The CDS improvements are comparable on their own to --dev, which is great,
and combining them with --dev is even more impressive. The CRuby numbers
are still 10x faster, but this is getting into a range where the difference
is tolerable.

I'm hoping AOTCache can help us eliminate the need for --dev. Tier 2 code
is still much slower than tier 1 code.

> On 2/12/25 10:37 AM, Charles Oliver Nutter wrote:
>
> * OMG that warning output... is there any way to capture that to a file
> without redirecting the whole process?
> * Why is it not possible to boot with one JSA and then dump a new JSA at
> the end? It complains if I use both SharedArchiveFile and
> ArchiveClassesAtExit in the same command line.
>
>
> That's something we are talking about in the Leyden project - train with
> an existing cache and write an updated cache at the end. What kinds of
> scenarios are you looking at?
>
My interest right now is entirely startup time, which is honestly the only
reason JRuby hasn't seem more success in Ruby shops. When we take 10x
longer to start up small commands, people just walk away.

Longer term, we are interested in pre-training the AOT cache specific to a
user's application, suitable for deploying a hotter image to a server. I
have also been exploring CRaC for that, but it has serious limitations.

We are looking forward to a future where we can precompile all of the Ruby
standard library to JRuby .class output and have it boot up with cached AOT
for whatever you happen to use during your command. We're also planning to
start pre-generating CDS stuff when publishing container images for e.g.
Docker.

> Have you tried the -XX:+AutoCreateSharedArchive flag? It should recreate
> the dynamic archive if you have updated the app's JAR files or updated to a
> new JDK.
>
This is definitely what we want for the JRuby launcher! I've integrated it
into the launcher and it seems to work well (my log redirects must still be
included to silence CDS warnings, though):

$ rm -f lib/jruby.jsa
$ time bin/jruby.sh -e 1
bin/jruby.sh -e 1  2.90s user 0.22s system 139% cpu 2.230 total
$ time bin/jruby.sh -e 1
bin/jruby.sh -e 1  1.79s user 0.11s system 176% cpu 1.081 total
$ ls -l lib/jruby.jsa
-r--r--r--  1 headius  staff  32489472 Feb 12 16:14 lib/jruby.jsa

I'm keen to play with the preview of AOTCache in 24. If anyone else wants
to try this stuff with JRuby, building JRuby is just "clone repo" and then
"run ./mvnw". The launcher is bin/jruby at that point and it's just POSIX
shell.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20250212/d4862cff/attachment.htm>