Conversation
When GTO removes fields or makes them immutable, it may introduce an immutable externref first field on the descriptor of a JS-exposed type where there was none before. That means that the described type could now have a JS-observable prototype where it did not before optimization, which makes this a misoptimization. Fix the problem by inserting an i8 placeholder first field wherever we would otherwise start exposing a prototype where there was none before. This is expected to be exceptionally rare in practice, so the extra memory use is not expected to be a real problem. Instead of adding a placeholder field, we could have inhibited optimization of the existing first field, but that would be more likely than an unaccessed placeholder field to have adverse effects in later passes. Fixes #9026.
kripken
reviewed
Aug 27, 2026
| ;; CHECK-NEXT: (type $struct (descriptor $desc) (struct)) | ||
| (type $struct (descriptor $desc) (struct)) | ||
| ;; CHECK: (type $desc (describes $struct) (struct (field i8) (field externref))) | ||
| (type $desc (describes $struct) (struct (field (mut externref)))) |
Member
There was a problem hiding this comment.
It's not clear to me why you say this would be "exceptionally rare" in practice? Because externrefs are rare? Otherwise, a mutable one seems common, and in the first slot also seems common.
Externrefs to represent strings and other JS content may be pretty common in some situations?
kripken
reviewed
Aug 27, 2026
kripken
left a comment
kripken
left a comment
Member
There was a problem hiding this comment.
Also, I am uneasy with this tradeoff. The benefits of immutability are large in general, but less so for an externref field (there is no constant we can propagate). And adding an i8 is a definite cost. I would actually lean towards the opposite tradeoff?
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
2 participants
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.
When GTO removes fields or makes them immutable, it may introduce an immutable externref first field on the descriptor of a JS-exposed type where there was none before. That means that the described type could now have a JS-observable prototype where it did not before optimization, which makes this a misoptimization.
Fix the problem by inserting an i8 placeholder first field wherever we would otherwise start exposing a prototype where there was none before. This is expected to be exceptionally rare in practice, so the extra memory use is not expected to be a real problem.
Instead of adding a placeholder field, we could have inhibited optimization of the existing first field, but that would be more likely than an unaccessed placeholder field to have adverse effects in later passes.
Fixes #9026.