[squeak-dev] Modifying a method's bytecodes ... is it supported?

Eliot Miranda eliot.miranda at gmail.com
Fri Apr 3 18:53:40 UTC 2020


Hi Marcel,

On Fri, Apr 3, 2020 at 10:02 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi, all!
>
> Are a method's bytecodes virtually read-only? There is no
> ModificationForbidden at the moment ...
>

Modification is allowed, and in a StackInterpeeter, will be obeyed
immediately,, BUT one cannot simply modify bytecodes and expect things to
change.  Because of the JIT one also has to flush any and all ached VM
state, in particular generated code, via CompiledCode>>voidCogVMState.  We
made heavy use of this facility at Cadence where we modified bytecodes to
install line-specific break-points (don't ask ;-) ).  I'm cc'ing Bob to see
if you, Bob, can remember where the tests are.  I've looked in
MethodMassage and there is only a simply test.  But IIRC we had a full
breakpoint test at one stage.

Now, if there is a different suggestion, that we make methods read-only, I
would support that.  Then we could formalize the use of
CompiledCode>>voidCogVMState, something like if one attempted to modify a
method, there would be an exception that one could proceed through and
somehow voidCogVMState would be invoked before resetting the method back to
being read-only.


Note that in ViualWorks methods are also not read-only (or weren't in 2007
when we did the immutability work).  I think methods *should* be read-only,
but in the Squeak context that means making them writable while their
source pointers are updated, etc.

> Best,
> Marcel

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200403/15aa70e7/attachment.html>


More information about the Squeak-dev mailing list