OpenSmalltalk
BitBlt ignores write barriers
I just noticed that primitiveCopyBits ignores write barriers as well. If destForm isReadOnlyObject or destForm bits isReadOnlyObjects, the primitive will manipulate the form anyway (presumably the remaining variables of the form are not protected as well; I did not test it).
It's not urgent, I just tested this out of curiosity :)
From: Eliot Miranda @.> Sent: Saturday, October 25, 2025 4:09:08 AM To: OpenSmalltalk/opensmalltalk-vm @.> Cc: Christoph Thiede @.>; Author @.> Subject: Re: [OpenSmalltalk/opensmalltalk-vm] BitBlt ignores write barriers (Issue #743)
[https://avatars.githubusercontent.com/u/15850192?s=20&v=4]eliotmiranda left a comment (OpenSmalltalk/opensmalltalk-vm#743)https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/743#issuecomment-3445482341
Good catch. I can fix this v soon.
— Reply to this email directly, view it on GitHubhttps://github.com/OpenSmalltalk/opensmalltalk-vm/issues/743#issuecomment-3445482341, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJH4PSVLJOIW3KR7M76RJBD3ZLLUJAVCNFSM6AAAAACKEY67DCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINBVGQ4DEMZUGE. You are receiving this because you authored the thread.Message ID: @.***>
Well, I shall start the work. I won't do all plugins. I'm aiming at all plugins but even this I can't complete because most of the Squeak3D plugin is written in C (see code in platforms/Cross/plugins/Squeak3D). But the others I shall fix.
The key to making it easy to do is to add stackMutableObjectValue: alongside squeakObjectValue:. Anything that uses stackObjectValue: must check for failure. So substituting stackMutableObjectValue: for squeakObjectValue: checks and fails for immutable objects.
I'm aiming at all plugins but even this I can't complete because most of the Squeak3D plugin is written in C (see code in platforms/Cross/plugins/Squeak3D).
Asking conceptually out of interest: why can the write barrier state of an oop not be exposed to C plugins via a header definition? Would that mainly be a linking problem or a more interesting challenge?
From: Eliot Miranda @.> Sent: Saturday, October 25, 2025 10:57:45 PM To: OpenSmalltalk/opensmalltalk-vm @.> Cc: Christoph Thiede @.>; Author @.> Subject: Re: [OpenSmalltalk/opensmalltalk-vm] BitBlt ignores write barriers (Issue #743)
[https://avatars.githubusercontent.com/u/15850192?s=20&v=4]eliotmiranda left a comment (OpenSmalltalk/opensmalltalk-vm#743)https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/743#issuecomment-3447764386
Well, I shall start the work. I won't do all plugins. I'm aiming at all plugins but even this I can't complete because most of the Squeak3D plugin is written in C (see code in platforms/Cross/plugins/Squeak3D). But the others I shall fix.
The key to making it easy to do is to add stackMutableObjectValue: alongside squeakObjectValue:. Anything that uses stackObjectValue: must check for failure. So substituting stackMutableObjectValue: for squeakObjectValue: checks and fails for immutable objects.
— Reply to this email directly, view it on GitHubhttps://github.com/OpenSmalltalk/opensmalltalk-vm/issues/743#issuecomment-3447764386, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJH4PSU3FFENDI2VSFRIYOL3ZPP4TAVCNFSM6AAAAACKEY67DCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTINBXG43DIMZYGY. You are receiving this because you authored the thread.Message ID: @.***>
Asking conceptually out of interest: why can the write barrier state of an oop not be exposed to C plugins via a header definition? Would that mainly be a linking problem or a more interesting challenge?
It's more the legacy design of the API. sqVirtualMachine.[ch]/struct VirtualMachine/InterpreterProxy provides a somewhat abstract API for plugins. I didn't want to rewrite this. One implication is that plugins can be compiled against either the V3 or the Spur systems.
BTW, you might think of writing a lint tool to analyze plugins that may violate read-onlyness. Take a look at the phrase tree analysis that is used to compute primitive accessor depths in Spur (codeGeneratorToComputeAccessorDepth;accessorDepthForMethod:interpreterClass:;accessorsAndAssignmentsForMethod:actuals:depth:interpreterClass:into: et al). This computes the length of chains of accesses from e.g. an object loaded from the stack, and objects loaded from that object, and so on. This is used to compute the depth of the object graph/tree that a primitive accesses so that on failure the inputs are traced to that depth looking for forwarders, forwarders are followed (eliminated) within the graph to that depth, and if any are found the primitive is retried, hence providing implicit forwarding for primitives.
A very similar analysis could look for stores into objects loaded by primitives, and check that objects stored into are tested for read-onlyness before they are stored into.