[Vm-dev] Proxies and primitives

Stefan Marr smalltalk at stefan-marr.de
Tue Jan 17 11:35:57 UTC 2012


On 17 Jan 2012, at 11:52, Mariano Martinez Peck wrote:

> Hi guys. I am experimenting with something that creates proxies automatically and become existing objects to those proxies. The objects I become with proxies are selected kind of automatically and they can be instances of any class. I have a list of classes that I don't become their instances since it seems I can easily crash the VM (such as SmallIntegers, Characters, Symbols, etc).  Now...with mi proxy implementation I can intercept almost all messages, so I don't have a problem with that. What I am thinking now is the problem of proxies that are passed as arguments to primitives. My question is if there can be primitives that assumes the type of the argument and do something directly. So if I send a proxy that doesn't respect the expected shape...it can answer something wrong or even crash. Another possibility is that the primitive fails normally (primitiveFailure) but then that there is no smalltalk code after the primitive invocation (I guess not all methods that use a primitive has the correct smalltalk code after).
> So.... Is this possible?  do you have an example? 

Example: the perform with super primitive. (if the expected array aint an array, you can expect at least your stack to get messed up on Cog)

My understanding is currently that primitives do not guarantee you anything if you violate their contract.

You can easily crash Cog since Eliot makes that assumption.

So, what you are doing is inherently dangerous, and requires you to adapt all primitives to handle these cases.

As I said, that is my current understanding. I think you should refer to the blue book and see what is discussed there with respect to primitives and guarantees.

Best regards
Stefan



-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525



More information about the Vm-dev mailing list