Repository navigation
Fix CleanBlockClosure/ConstantBlockClosure Tost materialization (dead startpc reference) - #10
Closed
oliveiraallex wants to merge 4 commits into
Closed
oliveiraallex wants to merge 4 commits into
oliveiraallex wants to merge 4 commits into
Conversation
… startpc reference)
TostSerializer's BlockClosure>>correctTostMaterializationWith: shifts a
`startpc` instance variable to correct for word-size differences when
materializing a block transferred by value. That variable belonged to
the pre-Pharo-11 block representation, where a BlockClosure embedded
its own bytecode inline in its instance-variable-adjacent storage.
Since Pharo 11's FullBlockClosure redesign, BlockClosure no longer
holds bytecode at all -- it's split into outerContext/compiledBlock/
numArgs, with compiledBlock a separate CompiledBlock object owning its
own bytecode and literals. `startpc` is a stale reference: reading it
now raises UndeclaredVariableRead, since the compiler resolves it to
an unbound global rather than a real instance variable.
FullBlockClosure already had a no-op override for this (someone
already handled that half of the hierarchy). CleanBlockClosure and its
subclass ConstantBlockClosure -- the other concrete block classes from
the same redesign, used for blocks needing no/only-constant outer
state (e.g. `[12]`, `[42]`) -- did not, and fell back to BlockClosure's
broken implementation, crashing on materialization with "Attempt to
read undeclared variable startpc".
Added mirrored no-op overrides on CleanBlockClosure:
- correctTostMaterializationWith: (no-op, nothing to correct)
- class>>createTostInstanceWith: (simplified to Object's basicNew:-based
instantiation, matching FullBlockClosure's approach)
- writeTostBodyWith: (simplified to Object's size-based serialization)
Confirmed via local Pharo 9 vs Pharo 11+ source comparison and Pharo 11
release notes ("Extended Full Blocks and Constant Clock closures
support") that this representation change landed in Pharo 11. Checked
the repo's other branches for an existing fix -- none found, including
origin/pharo9-deprecation-methods, which still carries the same broken
startpc code.
Verified live: `peer evaluate: [12]` -> 12, `peer evaluate: [1 + 2]` ->
3, both clean, no debuggers
Contributor
Author
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
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.
TostSerializer's BlockClosure>>correctTostMaterializationWith: shifts a
startpcinstance variable to correct for word-size differences whenmaterializing a block transferred by value. That variable belonged to
the pre-Pharo-11 block representation, where a BlockClosure embedded
its own bytecode inline in its instance-variable-adjacent storage.
Since Pharo 11's FullBlockClosure redesign, BlockClosure no longer
holds bytecode at all -- it's split into outerContext/compiledBlock/
numArgs, with compiledBlock a separate CompiledBlock object owning its
own bytecode and literals.
startpcis a stale reference: reading itnow raises UndeclaredVariableRead, since the compiler resolves it to
an unbound global rather than a real instance variable.
FullBlockClosure already had a no-op override for this (someone
already handled that half of the hierarchy). CleanBlockClosure and its
subclass ConstantBlockClosure -- the other concrete block classes from
the same redesign, used for blocks needing no/only-constant outer
state (e.g.
[12],[42]) -- did not, and fell back to BlockClosure'sbroken implementation, crashing on materialization with "Attempt to
read undeclared variable startpc".
Added mirrored no-op overrides on CleanBlockClosure:
instantiation, matching FullBlockClosure's approach)
Confirmed via local Pharo 9 vs Pharo 11+ source comparison and Pharo 11
release notes ("Extended Full Blocks and Constant Clock closures
support") that this representation change landed in Pharo 11. Checked
the repo's other branches for an existing fix -- none found, including
origin/pharo9-deprecation-methods, which still carries the same broken
startpc code.
Verified live on Pharo 13:
peer evaluate: [12]-> 12,peer evaluate: [1 + 2]->3, both clean, no debuggers