[squeak-dev] Do we need to provide the mirror primitive on Context (only)?

Marcel Taeumel marcel.taeumel at hpi.de
Wed Jan 12 08:35:45 UTC 2022

Hi Christoph --

This discussion looks like it affects our current ProtoObject/Proxy situation. So ... maybe move those mirror primitives to ProtoObject? Maybe class side?

Am 11.01.2022 22:52:36 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi Eliot, hi all,

as I have learned from your great explanation about stack frame states and marriage last year, using "thisContext" in your code is more expensive than one might assume naively when thinking of it as a simple variable. This also means that using "thisContext" for invoking a mirror primitive is (unnecessarily?) slow:

[thisContext object: World eqeq: World] bench. '28,000,000 per second. 35.8 nanoseconds per run. 19.13235 % GC time.' 


TestObject >> object: anObject eqeq: anOtherObject 
<primitive: 110>

self primitiveFailed

obj := TestObject new.
[obj object: World eqeq: World] bench '58,900,000 per second. 17 nanoseconds per run. 0 % GC time.' 

Twice as fast!

I am wondering whether it would be useful to copy or move the mirror primitive protocol to another place, maybe on the class-side of Context, given the number of senders to some mirror primitive methods which are different from Context. In particular, SimulationStudio makes heavy [https://sourcegraph.com/search?q=context:global+thisContext+object+repo:LinqLover/SimulationStudio&patternType=literal] use of them, but the BasicInspector, Squot, and some other tools use it, too. :-)

So here are my questions:
* Would this be a legitimate use of the mirror primitives or is the (implicit) contract that the receiver must be a context instance or even a context instance on the current stack?
* Do you consider the mirror primitive protocol a public protocol or are all senders from different classes actually abusing the protocol?
* How would you think about moving this protocol to a static place such as Context class?

Thanks in advance!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220112/be866138/attachment.html>

More information about the Squeak-dev mailing list