Force a Thread's block to optimize eagerly#8576
Merged
headius merged 1 commit intojruby:10-devfrom Jan 21, 2025
Merged
Conversation
The block of code passed to Thread.new is frequently only executed once during a program's runtime, and in such cases there's often heavy lifting performed within the block such as an IO or Queue loop. Because we do not support any form of on-stack replacement, these blocks may never fully optimize and will remain in whatever execution mode JRuby starts them in (usually the slowest "startup" interpreter). This patch adds logic from Thread.new into the block body to force completion of builds steps that would optimize the body. This is akin to the behavior of the command-line target script, which we also eagerly compile due to the great number of single-script utilities and benchmarks in the Ruby ecosystem. This patch also plumbs that force-ability through the other "buildable" execution units: methods and block-based methods like define_method. This may become useful in the future to have more direct control over when a target block or method optimizes.
Member
Author
|
Performance improvement based on the first attempt here: COMMAND BEFORE (note no JIT output except the failure to compile the -e script) AFTER (note JIT output and significant improvement in the performance of each thread's execution) |
Member
Author
|
Note idea came out of #8406, where a one-shot, long-running background thread services all timeouts. If that thread's code immediately optimized, it may be able to keep up with the onslaught of tiny timeout jobs. |
Member
Author
|
I experimented with this optimization and the timeout issue in #8406, and it does help, but the many client threads still swamp the one timeout thread. See ruby/timeout#58 for the ongoing issue. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The block of code passed to Thread.new is frequently only executed once during a program's runtime, and in such cases there's often heavy lifting performed within the block such as an IO or Queue loop. Because we do not support any form of on-stack replacement, these blocks may never fully optimize and will remain in whatever execution mode JRuby starts them in (usually the slowest "startup" interpreter).
This patch adds logic from Thread.new into the block body to force completion of builds steps that would optimize the body. This is akin to the behavior of the command-line target script, which we also eagerly compile due to the great number of single-script utilities and benchmarks in the Ruby ecosystem.
This patch also plumbs that force-ability through the other "buildable" execution units: methods and block-based methods like define_method. This may become useful in the future to have more direct control over when a target block or method optimizes.