[External] : Re: Hello from JRuby and here's another crash
ioi.lam at oracle.com
ioi.lam at oracle.com
Tue Jul 9 21:00:30 UTC 2024
On 7/8/24 9:04 AM, Charles Oliver Nutter wrote:
> The patched build does indeed work, and cuts JRuby's base startup time
> by 50%! Bravo!
>
> $ time jruby -e 1
> jruby -e 1 3.53s user 0.14s system 276% cpu 1.326 total
> $ time jruby -J-XX:CacheDataStore=jruby.cds -e 1
> jruby -J-XX:CacheDataStore=jruby.cds -e 1 2.38s user 0.19s system
> 385% cpu 0.667 total
>
> This is a very promising start and the largest single improvement we
> have seen. Comparison with our previous champion, C1:
>
> $ time jruby --dev -e 1
> jruby --dev -e 1 1.22s user 0.09s system 142% cpu 0.922 total
>
> Interestingly, when I try to use the previously trained CDS dump (via
> 100.times { org.jruby.Ruby.newInstance }) with a command line that
> forces C1 (--dev flag passes -XX:TieredStopAtLevel=1) I get a
> different crash:
> https://gist.github.com/headius/d3138efa52eed9c678414c8cfe08af27
> <https://urldefense.com/v3/__https://gist.github.com/headius/d3138efa52eed9c678414c8cfe08af27__;!!ACWV5N9M2RV99hQ!O1UAeB7nD1zEm6bMPw7oDGNPEmvkkh6jK5YVmZJVKQP6Ugi5tSURjYzIpMvg0XmXhF6oaTom1wRsn5A$>
>
I filed https://bugs.openjdk.org/browse/JDK-8336033 . It looks like a
simple book keeping issue in the compiler code.
> I'm wondering what else I can do to try to train the CDS dump better,
> so that a larger command (jruby -S gem list) sees more improvement
> (this loads a bunch more Ruby code into the interpreter):
>
> $ time jruby -S gem list > /dev/null
> jruby -S gem list > /dev/null 6.41s user 0.26s system 236% cpu 2.821
> total
> $ time jruby -J-XX:CacheDataStore=jruby.cds -S gem list > /dev/null
> jruby -J-XX:CacheDataStore=jruby.cds -S gem list > /dev/null 5.84s
> user 0.32s system 294% cpu 2.089 total
>
Does this load a lot of dynamically generated classes? The current set
of Leyden optimizations are mostly for classes loaded in the built-in
loaders (boot/platform/app).
I wonder how much of the time is spend in one-time activity. If you run
the above inside a loop (2x, 4x, 8x, 16x, etc), how does it scale?
I think if we see a big drop between 1x vs 2x, then perhaps the current
set of Leyden optimizations can help (as long as most of the time is
spent in the built-in loaders).
In any case, dynamic language runtimes like jruby probably have very
different start-up characteristics than, say, your typical "micro
service" Java app. More analysis is needed.
Thanks
- Ioi
> - Charlie
>
> On Thu, Jul 4, 2024 at 11:50 PM <ioi.lam at oracle.com> wrote:
>
> Hi Charlie,
>
> Thanks for the bug report.
>
> It turns out some Leyden optimizations can't handle the module
> options specified by jruby, such as these:
>
> --add-opens=java.base/java.nio.channels=org.jruby.dist
> --module-path=/xxxx/jruby-9.4.8.0/lib/jruby.jar
>
> I filed https://bugs.openjdk.org/browse/JDK-8335735
>
> I'll work on a proper fix. Meanwhile, I have a work-around in this
> branch
>
> https://github.com/iklam/jdk/tree/work-around-8335735-jruby-crash-due-to-lack-of-module-support
> <https://urldefense.com/v3/__https://github.com/iklam/jdk/tree/work-around-8335735-jruby-crash-due-to-lack-of-module-support__;!!ACWV5N9M2RV99hQ!O1UAeB7nD1zEm6bMPw7oDGNPEmvkkh6jK5YVmZJVKQP6Ugi5tSURjYzIpMvg0XmXhF6oaTomY2MJITU$>
>
> If you build a JDK from this source branch, you can see the
> following improvements:
>
> # [1] No optimizations
> $ time env JAVA_HOME=$MYJAVA
> ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
> -e '10.times { org.jruby.Ruby.newInstance }'
> real 0m3.215s
> user 0m14.868s
> sys 0m0.373s
>
>
> # [2] Leyden
> $ time env JAVA_HOME=$TBP0 ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
> -J-XX:CacheDataStore=jruby.cds \
> -e '10.times { org.jruby.Ruby.newInstance }'
> real 0m1.880s
> user 0m9.001s
> sys 0m0.268s
>
>
> # [3] Compare with CDS in the JDK mainline
> $ env JAVA_HOME=$MYJAVA ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
> -J-XX:DumpLoadedClassList=jruby.classlist \
> -e '10.times { org.jruby.Ruby.newInstance }'
> $ $MYJAVA/bin/java -Xshare:dump \
> --module-path=/home/iklam/Downloads/ruby/jruby-9.4.8.0/lib/jruby.jar \
> -XX:SharedClassListFile=jruby.classlist \
> -XX:SharedArchiveFile=jruby.jsa -Xlog:cds
> $ time env JAVA_HOME=$MYJAVA
> ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
> -J-XX:SharedArchiveFile=jruby.jsa \
> -e '10.times { org.jruby.Ruby.newInstance }'
> real 0m2.628s
> user 0m13.007s
> sys 0m0.428s
>
> Please try it out and let us know if you run into other problems.
>
> Thanks
>
> - Ioi
>
>
> On 7/4/24 1:06 PM, Charles Oliver Nutter wrote:
>> Hello friends! Long time lurker, first time poster.
>>
>> Like others I was excited to hear that the first EA of Leyden had
>> dropped. Sadly, I have another crash to report.
>>
>> I see there are two other crashes reported, but mine appears
>> different (ClassPrelinker::is_indy_resolution_deterministic):
>>
>> https://gist.github.com/headius/79c6460ed55c1d80c82e1c0209897e24
>> <https://urldefense.com/v3/__https://gist.github.com/headius/79c6460ed55c1d80c82e1c0209897e24__;!!ACWV5N9M2RV99hQ!O1UAeB7nD1zEm6bMPw7oDGNPEmvkkh6jK5YVmZJVKQP6Ugi5tSURjYzIpMvg0XmXhF6oaTomO4igb9c$>
>>
>> Perhaps unsurprisingly, the additional flags provided by Vladimir
>> Kozlov (-XX:+UnlockDiagnosticVMOptions
>> -XX:-ReduceAllocationMerges) did not appear to change the result.
>>
>> This is with JRuby's minimally invokedynamic-based mode, which
>> has given us the shortest startup time in the past (second only
>> to disabling tiers 2-4 and staying in C1).
>>
>> I am on MacOS AArch64 Sonoma 14.5, testing against JRuby master,
>> but reproduction should be as easy as downloading the JRuby
>> binary tarball, unpacking, and running bin/jruby with the command
>> line above.
>>
>> https://www.jruby.org/download
>> <https://urldefense.com/v3/__https://www.jruby.org/download__;!!ACWV5N9M2RV99hQ!O1UAeB7nD1zEm6bMPw7oDGNPEmvkkh6jK5YVmZJVKQP6Ugi5tSURjYzIpMvg0XmXhF6oaTom4BSxN20$>
>>
>> I am eager to work with Leyden folks to investigate issues, and I
>> am planning to be at JVMLS this year to discuss collaborating more!
>>
>> - Charlie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240709/bbba94d5/attachment.htm>
More information about the leyden-dev
mailing list