-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Root current opline result after GC #19787
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
Draft
+385
−104
Conversation
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
@arnaud-lb
arnaud-lb
force-pushed
the
gh13687
branch
from
September 10, 2025 16:04
d451c52
to
3cb08bc
Compare
@arnaud-lb
arnaud-lb
force-pushed
the
gh13687
branch
from
September 11, 2025 16:04
3cb08bc
to
4fe6a47
Compare
@arnaud-lb
arnaud-lb
force-pushed
the
gh13687
branch
from
September 11, 2025 16:35
4fe6a47
to
f03f4db
Compare
In JIT:
- Using exits to handle interrupts is useful to make sure that we have a consistent view of the stack in GC. It also keeps the code size small.
- However, the exit may be eventually blacklisted as vm_interrupt will be set more often
- We could introduce a new exit kind that doesn't blacklist
- Alternatively we could exit manually, provided that we handle deoptimization
- WDYT @dstogov?
@arnaud-lb
arnaud-lb
force-pushed
the
gh13687
branch
from
September 12, 2025 08:41
f03f4db
to
94ddcdf
Compare
dstogov
dstogov
reviewed
Sep 15, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think delaying GC until interrupt handler has its advantages, but this is a significant change that may cause regressions.
I can't dedicate significant time to this task.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Uh oh!
There was an error while loading. Please reload this page.
Possible fix for GH-13687.
GH-13687 TL;DR:
php-src/Zend/zend_gc.c
Lines 2213 to 2216 in 05eda43
This implements two main changes:
The latter point is needed so that we can have some expectations about the VM state (e.g. the last opline's result is initialized), and it's a good thing regardless of this bug, IMHO (e.g. #17246).
There are a few things to consider:
EX(opline)
set to the nextopline
to execute, not the last one executed. So I root the inputs ofEX(opline)
instead: IfEX(opline)
consumes the result of the previously executed opline, it will be one of the inputs.