GBS question about customizing #attemptedROMStore:intoSlot:

[Richard Sargent]

GBS uses a "technique" to override #attemptedROMStore:intoSlot: with a custom method that allows GBS to detect changes to objects, so it knows when dirty objects need to be replicated back to the server.

The Core registry holds a reference to this selector, so I have to wonder whether one could replace the registry entry with a custom selector.

Core registry at: 4
 #attemptedROMStore:intoSlot:
(Core registry at: 4) isInFixedSpace
 true

e.g.
Core registry at: 4 put: #gbs_attemptedROMStore:intoSlot: makeFixed.

Could one do that?
If so, must it be done at a specific point in time (during the life cycle of the image)?

Or would it simply become effective immediately?

I understand an error in that method would be catastrophic for the image. That's why we ensure we can build images from scratch. We can afford to lose one for any reason.

[Marcus Wagner]

Richard,

I assume in ClassA, method b a specific call of #x has to be replaced by #z. 

Thus oldSelector #x has to become newSelector #z, the call to be patched takes place in ClassA>#b. So

ClassA>>b

 self x

becomes

ClassA>>b

 self z

Patching the call of a method has the benefit to be reversable. You can reverse your modification if you run this with x z parameter exchanged. Here the method doing this patch

replaceSelector: oldSelector by: newSelector inClass: callingClass method: callerSelector
"Replace old selector by a new selector in a method of a class"

| cm original |

cm := (original := callingClass compiledMethodAt: callerSelector) emDecodableMethod.
cm filePointer: original filePointer.
cm methodClass methodDictionary add: cm.
cm markReadOnly: false.
[1 to: cm literalSize do: [:i | (cm at: i) = oldSelector ifTrue: [cm at: i put: newSelector]]]
ensure: [cm markReadOnly: true]

An example in using this

self replaceSelector:  #x by: #z inClass:  ClassA method: #b

Undoing this

self replaceSelector:  #z by: #x inClass:  ClassA method: #b

I apply this in the development image. Packaging the patched method is untested. That means, it depends wether the original call or the patched call is packaged. in the latter case, the patch has to be redone at runtime.

Kind regards

M

[Mariano Martinez Peck]

Hi Richard,

The VM reads the selector needed to send the things like that directly from the registry object, so changing the selector will have effect immediately (at the next rom store attempt).

Regards,

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/e7df2f8a-045b-45ae-addf-5119931442aen%40googlegroups.com.

--

Mariano Martinez Peck VAST Lead Consultant Senior Software Engineer  mp...@instantiations.com  @MartinezPeck  /mariano-martinez-peck  instantiations.com

[Richard Sargent]

On Tue, Apr 7, 2026 at 10:38 AM 'Mariano Martinez Peck' via VAST Community Forum <va-sma...@googlegroups.com> wrote:

Hi Richard,

The VM reads the selector needed to send the things like that directly from the registry object, so changing the selector will have effect immediately (at the next rom store attempt).

Thanks for confirming that!

 

You received this message because you are subscribed to a topic in the Google Groups "VAST Community Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/TvPEOcFh8nM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to va-smalltalk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/CAOUkibHXrDCnUU_t9nBeyiR_S4p9h_V%2B9h0Y0GVr-TLtEf3FCg%40mail.gmail.com.