Modifying a method's bytecodes ... is it supported?
Locked
Modifying a method's bytecodes ... is it supported?
 
|
Hi, all! Are a method's bytecodes virtually read-only? There is no ModificationForbidden at the moment ... Best, Marcel |
Re: Modifying a method's bytecodes ... is it supported?
|
Hi Marcel, On Fri, Apr 3, 2020 at 10:02 AM Marcel Taeumel <[hidden email]> wrote:
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 |
Re: Modifying a method's bytecodes ... is it supported?
|
|
> Now, if there is a different suggestion, that we make methods read-only, I would support that.
If you are talking about making methods read-only, are you also intending to deprecate #literalAt:put:? I'm asking because this one is actually used by the workspace to create dynamic bindings.
However, I have been never convinced why we need to store these bindings in the method itself. The debugger does not even support that (you can neither view these bindings in one of the debugger's inspectors, nor they are styled correctly) what is a pity IMHO. Can we give each workspace a uniclass instance as doItReceiver, and store dynamic bindings as its instance variables instead of method literals? This change should not break anything important (retained behavior: all codes that are run in one workspace access the same variables), but it would a) improve the user experience as you could watch the variables in the debugger's inspector like regular variables, and b) allow us to make methods completely read-only. Or would it be too confusing if [self class] in a Workspaces printed out something like "Object17" or "UndefinedObject17" rather than "UndefinedObject"?
PS: Sorry for abducting this topic into the domain of Tools! :-)
Best, Christoph Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Freitag, 3. April 2020 20:53:40 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Modifying a method's bytecodes ... is it supported? Hi Marcel,
On Fri, Apr 3, 2020 at 10:02 AM Marcel Taeumel <[hidden email]> wrote:
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
Carpe Squeak!
|
Re: Modifying a method's bytecodes ... is it supported?
|
|
Please pardon the objection. I realized just now that these literal bindings are not actually stored directly inside of the method, but rather as nested associations. This would not be affected by the proposal to make the method objects read-only, I assume?
Anyway, literal variables are an interesting concept. I could not find any stuff about the decision to use it in Workspaces, but I probably don't know about it. I'd be happy to learn more about this concept if you could give me some pointers. :-)
Best, Christoph Von: Thiede, Christoph
Gesendet: Freitag, 3. April 2020 21:17:23 An: The general-purpose Squeak developers list Betreff: AW: [squeak-dev] Modifying a method's bytecodes ... is it supported? > Now, if there is a different suggestion, that we make methods read-only, I would support that.
If you are talking about making methods read-only, are you also intending to deprecate #literalAt:put:? I'm asking because this one is actually used by the workspace to create dynamic bindings.
However, I have been never convinced why we need to store these bindings in the method itself. The debugger does not even support that (you can neither view these bindings in one of the debugger's inspectors, nor they are styled correctly) what is a pity IMHO. Can we give each workspace a uniclass instance as doItReceiver, and store dynamic bindings as its instance variables instead of method literals? This change should not break anything important (retained behavior: all codes that are run in one workspace access the same variables), but it would a) improve the user experience as you could watch the variables in the debugger's inspector like regular variables, and b) allow us to make methods completely read-only. Or would it be too confusing if [self class] in a Workspaces printed out something like "Object17" or "UndefinedObject17" rather than "UndefinedObject"?
PS: Sorry for abducting this topic into the domain of Tools! :-)
Best, Christoph Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Freitag, 3. April 2020 20:53:40 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Modifying a method's bytecodes ... is it supported? Hi Marcel,
On Fri, Apr 3, 2020 at 10:02 AM Marcel Taeumel <[hidden email]> wrote:
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
Carpe Squeak!
|
| Free forum by Nabble | Edit this page |