Conversation
|
JRuby startup times for Much of the slowdown does appear to be related to loading the Chicory WASM subsystem. Here are the biggest delays during a cached (AppCDS) This hit seems to be common to both modes and probably relates to the loading of the jffi shared library: There are a few jumps here while loading Chicory internals needed to parse the WASM and connect to Redline: The After this point, things seem to be up and running and the remaining class loads happen with fairly little delay. Total time for this run was 2.950s. I suspect we are not getting the full benefit of AppCDS for some of the Chicory AOT compiled stuff, perhaps because it's too large. This was tested on JDK 25. cc @andreaTP FYI |
|
This merge can wait until the Endive migration for the WASM Prism has been released, but it's not a prerequisite (none of the code in JRuby directly references Chicory). See ruby/prism#4229 |
|
Kinda feels like this should be under org.jruby.parser.prism and what's in org.jruby.parser should move to org.jruby.parser.legacy or similar. cc @enebo for thoughts |
|
I have discovered and am in the process of fixing a JFFI bug causing it to always write out a new dynamic library file each time on MacOS, which greatly improves startup time. The increase from loading Prism remains very high, however: (both times after warming up OS and JVM caches) |
This library lived previously as the jruby-prism artifact, during a time when we expected to be updating its code independently of JRuby proper. This was also done at a time when we still depended on the native library build of Prism, which introduced various challenges to shipping a cross-platform artifact. Updates over the last year have brought the parser and compiler more closely in line with JRuby's built-in legacy parser, and the use of new WASM AOT features from Chicory Redline we can now include the parser in JRuby out of the box. Having this be a separate project and artifact just gets in the way of us fully adopting Prism. This patch moves the contents of jruby-prism into JRuby core. Note that loading the current WASM AOT version of the Prism parser impacts performance by about 30%. Before it can be fully enabled we need to address this startup hit along with the remaining language compatibility issues.
a141283 to
3f902b0
Compare
|
Updated to use 0.0.5-SNAPSHOT of the prism parser artifact, which moves to Endive. |
This is suspicious, do you have a direct link to where the Wasm Instance is being created? |
|
@headius I was testing redline on QuickJs and found a few things to be improved, let me iterate and get back when I publish the next version. |
|
@andreaTP The actual code for this still lives in the ruby/prism project so that's the place to look. This PR just eliminates a middleman project we were using to isolate JRuby from the native library. I haven't had a chance to get the new endive version of prism released. |
2 participants
This library lived previously as the jruby-prism artifact, during a time when we expected to be updating its code independently of JRuby proper. This was also done at a time when we still depended on the native library build of Prism, which introduced various challenges to shipping a cross-platform artifact.
Updates over the last year have brought the parser and compiler more closely in line with JRuby's built-in legacy parser, and the use of new WASM AOT features from Chicory Redline we can now include the parser in JRuby out of the box. Having this be a separate project and artifact just gets in the way of us fully adopting Prism.
This patch moves the contents of jruby-prism into JRuby core.
Note that loading the current WASM AOT version of the Prism parser impacts performance by about 30%. Before it can be fully enabled we need to address this startup hit along with the remaining language compatibility issues.