What is the best way to load Ghost in Pharo 3.0? Is there a configuration somewhere? Is anyone using it? Voyage does seem to use the ProtoObject+dnu+becomeForward trick. Is there any reason for that?
Hi François, The code is here http://ss3.gemstone.com/ss/Ghost.html/Latest the configuration is working but I do not remember if I tested in Pharo 3 now Cheers, #Luc 2014-05-20 18:15 GMT+02:00 François Stephany <tulipe.moutarde@gmail.com>:
What is the best way to load Ghost in Pharo 3.0? Is there a configuration somewhere?
Is anyone using it? Voyage does seem to use the ProtoObject+dnu+becomeForward trick. Is there any reason for that?
In general, we should think about if is would make sense that the language comes with a good proxy model by default. (this way we would avoid that everyone creates one that is not completely working) On 21 May 2014, at 08:31, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi François,
The code is here http://ss3.gemstone.com/ss/Ghost.html/Latest the configuration is working but I do not remember if I tested in Pharo 3 now
Cheers,
#Luc
2014-05-20 18:15 GMT+02:00 François Stephany <tulipe.moutarde@gmail.com>: What is the best way to load Ghost in Pharo 3.0? Is there a configuration somewhere?
Is anyone using it? Voyage does seem to use the ProtoObject+dnu+becomeForward trick. Is there any reason for that?
2014-05-21 8:37 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:
In general, we should think about if is would make sense that the language comes with a good proxy model by default. (this way we would avoid that everyone creates one that is not completely working)
I completely agree with that. I think that most people come back to DNU because it is there and simple to implement. But some others also told me that they use a different design from the one of Ghost and I do not know what they change and why. Luc
On 21 May 2014, at 08:31, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi François,
The code is here http://ss3.gemstone.com/ss/Ghost.html/Latest the configuration is working but I do not remember if I tested in Pharo 3 now
Cheers,
#Luc
2014-05-20 18:15 GMT+02:00 François Stephany <tulipe.moutarde@gmail.com>:
What is the best way to load Ghost in Pharo 3.0? Is there a configuration somewhere?
Is anyone using it? Voyage does seem to use the ProtoObject+dnu+becomeForward trick. Is there any reason for that?
Cool, thanks ! I'll let you know if I run into any trouble on Pharo 3. On Wed, May 21, 2014 at 8:43 AM, Luc Fabresse <luc.fabresse@gmail.com>wrote:
2014-05-21 8:37 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:
In general, we should think about if is would make sense that the language
comes with a good proxy model by default. (this way we would avoid that everyone creates one that is not completely working)
I completely agree with that. I think that most people come back to DNU because it is there and simple to implement.
But some others also told me that they use a different design from the one of Ghost and I do not know what they change and why.
Luc
On 21 May 2014, at 08:31, Luc Fabresse <luc.fabresse@gmail.com> wrote:
Hi François,
The code is here http://ss3.gemstone.com/ss/Ghost.html/Latest the configuration is working but I do not remember if I tested in Pharo 3 now
Cheers,
#Luc
2014-05-20 18:15 GMT+02:00 François Stephany <tulipe.moutarde@gmail.com>:
What is the best way to load Ghost in Pharo 3.0? Is there a configuration somewhere?
Is anyone using it? Voyage does seem to use the ProtoObject+dnu+becomeForward trick. Is there any reason for that?
We will discuss. Stef
2014-05-21 8:37 GMT+02:00 Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>>:
In general, we should think about if is would make sense that the language comes with a good proxy model by default. (this way we would avoid that everyone creates one that is not completely working)
I completely agree with that. I think that most people come back to DNU because it is there and simple to implement.
But some others also told me that they use a different design from the one of Ghost and I do not know what they change and why.
Luc
On 21 May 2014, at 08:31, Luc Fabresse <luc.fabresse@gmail.com <mailto:luc.fabresse@gmail.com>> wrote:
Hi François,
The code is here http://ss3.gemstone.com/ss/Ghost.html/Latest the configuration is working but I do not remember if I tested in Pharo 3 now
Cheers,
#Luc
2014-05-20 18:15 GMT+02:00 François Stephany <tulipe.moutarde@gmail.com <mailto:tulipe.moutarde@gmail.com>>:
What is the best way to load Ghost in Pharo 3.0? Is there a configuration somewhere?
Is anyone using it? Voyage does seem to use the ProtoObject+dnu+becomeForward trick. Is there any reason for that?
On 22 mai 2014, at 11:54, stepharo <stepharo@free.fr> wrote:
In general, we should think about if is would make sense that the language comes with a good proxy model by default.
+ 1 We should do that with Camille.
Yes. Now the problem is to agree on what is a "good model". There is many use cases for proxies and they come with their own models and problems. Here are some requirements I can think of: - Uniformity: all objects can be wrapped, even special ones (it's a technicality but it's still important) - Interception of all message: currently we cannot intercept #== and optimized control-flow messages like #ifTrue:ifFalse #to:do:, #whileTrue:, etc... - Encapsulation (a.k.a the self problem): avoid leaking of references to the target. E.g. "aProxy yourself" should return the proxy not the target. - Behavioral intercession: Not everything is a message send. What other events do we want to intercept? IV access is a must-have for me. - Composition: Wrapping a proxy with another one should work as expected, i.e. applying both policies in order. - Performances: intercepting message sends is slow, intercepting iv accesses is even worse (relying on code instrumentation). We would need VM support. - Security: It shouldn't be possible to by-pass or corrupt a proxy policy. - Delimited replacement: Ensure that a proxy is always used in place of its target throughout the processing of a message send, no matter the alias used (that is not necessarily "self"). Think about a read-only proxy for example. Right now, to intercept messages we have to rely on #cannotInterpret: hack. To intercept iv access or other events we have to rely on code instrumentation and delegation. It would be easier if the VM would allow to create an object that controls its own interpretation (via a metaobject that defines a MOP for example). Such an object should at least be able to specify its message lookup and how to reads and writes IVs. And optionally: - how it sends messages - how it resolves other variables (temporaries, arguments, globals, class variables) - how it resolves literals - how it executes primitives (because else the VM may cry) - how it is assigned to a variable or passed in a message (to control static/dynamic aliasing respectively) - ... many others ... With such objects (+ operating by delegation instead of forwarding) we can solve most of the requirements listed above (well except performant delimited replacement). All that to say that it is not easy...
(this way we would avoid that everyone creates one that is not completely working)
2014-05-22 18:06 GMT+02:00 Camille Teruel <camille.teruel@gmail.com>:
On 22 mai 2014, at 11:54, stepharo <stepharo@free.fr> wrote:
In general, we should think about if is would make sense that the
language comes with
a good proxy model by default.
+ 1 We should do that with Camille.
Yes. Now the problem is to agree on what is a "good model". There is many use cases for proxies and they come with their own models and problems.
yes sure
Here are some requirements I can think of:
- Uniformity: all objects can be wrapped, even special ones (it's a technicality but it's still important) - Interception of all message: currently we cannot intercept #== and optimized control-flow messages like #ifTrue:ifFalse #to:do:, #whileTrue:, etc... - Encapsulation (a.k.a the self problem): avoid leaking of references to the target. E.g. "aProxy yourself" should return the proxy not the target. - Behavioral intercession: Not everything is a message send. What other events do we want to intercept? IV access is a must-have for me. - Composition: Wrapping a proxy with another one should work as expected, i.e. applying both policies in order. - Performances: intercepting message sends is slow, intercepting iv accesses is even worse (relying on code instrumentation). We would need VM support. - Security: It shouldn't be possible to by-pass or corrupt a proxy policy. - Delimited replacement: Ensure that a proxy is always used in place of its target throughout the processing of a message send, no matter the alias used (that is not necessarily "self"). Think about a read-only proxy for example.
Right now, to intercept messages we have to rely on #cannotInterpret: hack
why do you call it a hack? do you consider DNU as hack too?
. To intercept iv access or other events we have to rely on code instrumentation and delegation.
yes but I would like to investigate if cannot achieve iv interception using special slots
It would be easier if the VM would allow to create an object that controls its own interpretation (via a metaobject that defines a MOP for example). Such an object should at least be able to specify its message lookup and how to reads and writes IVs. And optionally: - how it sends messages
this one is possible with cannotInterpret you intercept and then you decide what to do and maybe execute something else so you control message sending
- how it resolves other variables (temporaries, arguments, globals, class variables) - how it resolves literals - how it executes primitives (because else the VM may cry) - how it is assigned to a variable or passed in a message (to control static/dynamic aliasing respectively)
all of those ones are submethod level and yes Ghost stops at the object granularity currently
- ... many others ... With such objects (+ operating by delegation instead of forwarding) we can solve most of the requirements listed above (well except performant delimited replacement). All that to say that it is not easy...
yes but it is interesting ;-) and we also discuss "some parts" of that with Nick Luc
(this way we would avoid that everyone creates one that is not completely working)
On 22 mai 2014, at 19:07, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2014-05-22 18:06 GMT+02:00 Camille Teruel <camille.teruel@gmail.com>:
On 22 mai 2014, at 11:54, stepharo <stepharo@free.fr> wrote:
In general, we should think about if is would make sense that the language comes with a good proxy model by default.
+ 1 We should do that with Camille.
Yes. Now the problem is to agree on what is a "good model". There is many use cases for proxies and they come with their own models and problems.
yes sure
Here are some requirements I can think of:
- Uniformity: all objects can be wrapped, even special ones (it's a technicality but it's still important) - Interception of all message: currently we cannot intercept #== and optimized control-flow messages like #ifTrue:ifFalse #to:do:, #whileTrue:, etc... - Encapsulation (a.k.a the self problem): avoid leaking of references to the target. E.g. "aProxy yourself" should return the proxy not the target. - Behavioral intercession: Not everything is a message send. What other events do we want to intercept? IV access is a must-have for me. - Composition: Wrapping a proxy with another one should work as expected, i.e. applying both policies in order. - Performances: intercepting message sends is slow, intercepting iv accesses is even worse (relying on code instrumentation). We would need VM support. - Security: It shouldn't be possible to by-pass or corrupt a proxy policy. - Delimited replacement: Ensure that a proxy is always used in place of its target throughout the processing of a message send, no matter the alias used (that is not necessarily "self"). Think about a read-only proxy for example.
Right now, to intercept messages we have to rely on #cannotInterpret: hack
why do you call it a hack?
Because it's a hijack a safety check of the VM. We set the method dictionary of the proxy's class to nil (or of its superclass if the proxy must understand some messages). Since the VM doesn't know what to do with that, it calls #cannotInterpret: starting the lookup in the superclass of that class. This superclass then redefines #cannotInterpret: to hand over the message interception to the proxy's handler...
do you consider DNU as hack too?
Using it to implement proxies? Yes. But in addition, DNU is bad since you can only intercept messages that are not understood. And you can also by-pass the message the proxy does understand by sending directly #doesNotUnderstand: to the proxy with a specific message as argument.
. To intercept iv access or other events we have to rely on code instrumentation and delegation.
yes but I would like to investigate if cannot achieve iv interception using special slots
I doubt we can since it is the target's slots that are taken into account during compilation. Or else every slot in the system must be special => really poor performances.
It would be easier if the VM would allow to create an object that controls its own interpretation (via a metaobject that defines a MOP for example). Such an object should at least be able to specify its message lookup and how to reads and writes IVs. And optionally: - how it sends messages this one is possible with cannotInterpret you intercept and then you decide what to do and maybe execute something else so you control message sending
I was talking about interception of message sending (the message the target would have sent) not of interception of message reception (the living wage of any proxy implementation :) ). Like the others events, it also lies at the submethod level.
- how it resolves other variables (temporaries, arguments, globals, class variables) - how it resolves literals - how it executes primitives (because else the VM may cry) - how it is assigned to a variable or passed in a message (to control static/dynamic aliasing respectively)
all of those ones are submethod level and yes Ghost stops at the object granularity currently
- ... many others ... With such objects (+ operating by delegation instead of forwarding) we can solve most of the requirements listed above (well except performant delimited replacement). All that to say that it is not easy...
yes but it is interesting ;-) and we also discuss "some parts" of that with Nick
Great, let us know about the conclusions :)
Luc
(this way we would avoid that everyone creates one that is not completely working)
2014-05-22 19:49 GMT+02:00 Camille Teruel <camille.teruel@gmail.com>:
On 22 mai 2014, at 19:07, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2014-05-22 18:06 GMT+02:00 Camille Teruel <camille.teruel@gmail.com>:
On 22 mai 2014, at 11:54, stepharo <stepharo@free.fr> wrote:
In general, we should think about if is would make sense that the
language comes with
a good proxy model by default.
+ 1 We should do that with Camille.
Yes. Now the problem is to agree on what is a "good model". There is many use cases for proxies and they come with their own models and problems.
yes sure
Here are some requirements I can think of:
- Uniformity: all objects can be wrapped, even special ones (it's a technicality but it's still important) - Interception of all message: currently we cannot intercept #== and optimized control-flow messages like #ifTrue:ifFalse #to:do:, #whileTrue:, etc... - Encapsulation (a.k.a the self problem): avoid leaking of references to the target. E.g. "aProxy yourself" should return the proxy not the target. - Behavioral intercession: Not everything is a message send. What other events do we want to intercept? IV access is a must-have for me. - Composition: Wrapping a proxy with another one should work as expected, i.e. applying both policies in order. - Performances: intercepting message sends is slow, intercepting iv accesses is even worse (relying on code instrumentation). We would need VM support. - Security: It shouldn't be possible to by-pass or corrupt a proxy policy. - Delimited replacement: Ensure that a proxy is always used in place of its target throughout the processing of a message send, no matter the alias used (that is not necessarily "self"). Think about a read-only proxy for example.
Right now, to intercept messages we have to rely on #cannotInterpret: hack
why do you call it a hack?
Because it's a hijack a safety check of the VM. We set the method dictionary of the proxy's class to nil (or of its superclass if the proxy must understand some messages). Since the VM doesn't know what to do with that, it calls #cannotInterpret: starting the lookup in the superclass of that class. This superclass then redefines #cannotInterpret: to hand over the message interception to the proxy's handler...
I know the mechanism ;-) but to me it is not hack it is a clever idea that let the programmer to decide what to do at the image side to implement crazy stuff without modifying the VM The VM is simple (one interception hook) while it enables to capture a lot of things. Of course we can imagine something else at the VM side but the more code in the VM the less flexible it will be
do you consider DNU as hack too?
Using it to implement proxies? Yes. But in addition, DNU is bad since you can only intercept messages that are not understood. And you can also by-pass the message the proxy does understand by sending directly #doesNotUnderstand: to the proxy with a specific message as argument.
we also explained that in the Ghost paper... that is why cannotInterpret is better but yet incompelete to capture everything
. To intercept iv access or other events we have to rely on code instrumentation and delegation.
yes but I would like to investigate if cannot achieve iv interception using special slots
I doubt we can since it is the target's slots that are taken into account during compilation. Or else every slot in the system must be special => really poor performances.
I have no clear idea yet on that so I must have look and you are certainly right Luc
It would be easier if the VM would allow to create an object that controls
its own interpretation (via a metaobject that defines a MOP for example). Such an object should at least be able to specify its message lookup and how to reads and writes IVs. And optionally: - how it sends messages
this one is possible with cannotInterpret you intercept and then you decide what to do and maybe execute something else so you control message sending
I was talking about interception of message sending (the message the target would have sent) not of interception of message reception (the living wage of any proxy implementation :) ). Like the others events, it also lies at the submethod level.
- how it resolves other variables (temporaries, arguments, globals, class
variables) - how it resolves literals - how it executes primitives (because else the VM may cry) - how it is assigned to a variable or passed in a message (to control static/dynamic aliasing respectively)
all of those ones are submethod level and yes Ghost stops at the object granularity currently
- ... many others ...
With such objects (+ operating by delegation instead of forwarding) we can solve most of the requirements listed above (well except performant delimited replacement). All that to say that it is not easy...
yes but it is interesting ;-) and we also discuss "some parts" of that with Nick
Great, let us know about the conclusions :)
Luc
(this way we would avoid that everyone creates one that is not completely working)
On 22 mai 2014, at 22:29, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2014-05-22 19:49 GMT+02:00 Camille Teruel <camille.teruel@gmail.com>:
On 22 mai 2014, at 19:07, Luc Fabresse <luc.fabresse@gmail.com> wrote:
2014-05-22 18:06 GMT+02:00 Camille Teruel <camille.teruel@gmail.com>:
On 22 mai 2014, at 11:54, stepharo <stepharo@free.fr> wrote:
In general, we should think about if is would make sense that the language comes with a good proxy model by default.
+ 1 We should do that with Camille.
Yes. Now the problem is to agree on what is a "good model". There is many use cases for proxies and they come with their own models and problems.
yes sure
Here are some requirements I can think of:
- Uniformity: all objects can be wrapped, even special ones (it's a technicality but it's still important) - Interception of all message: currently we cannot intercept #== and optimized control-flow messages like #ifTrue:ifFalse #to:do:, #whileTrue:, etc... - Encapsulation (a.k.a the self problem): avoid leaking of references to the target. E.g. "aProxy yourself" should return the proxy not the target. - Behavioral intercession: Not everything is a message send. What other events do we want to intercept? IV access is a must-have for me. - Composition: Wrapping a proxy with another one should work as expected, i.e. applying both policies in order. - Performances: intercepting message sends is slow, intercepting iv accesses is even worse (relying on code instrumentation). We would need VM support. - Security: It shouldn't be possible to by-pass or corrupt a proxy policy. - Delimited replacement: Ensure that a proxy is always used in place of its target throughout the processing of a message send, no matter the alias used (that is not necessarily "self"). Think about a read-only proxy for example.
Right now, to intercept messages we have to rely on #cannotInterpret: hack
why do you call it a hack?
Because it's a hijack a safety check of the VM. We set the method dictionary of the proxy's class to nil (or of its superclass if the proxy must understand some messages). Since the VM doesn't know what to do with that, it calls #cannotInterpret: starting the lookup in the superclass of that class. This superclass then redefines #cannotInterpret: to hand over the message interception to the proxy's handler...
I know the mechanism ;-)
I know you know, but there is many people on this mailing list :). It was to stress that we need three indirections (1st lookup, 2nd lookup, forward request to handler) where 1 would be enough if done at the vm side. I call it a hack but it's not pejorative. It's the best we can do without vm modification after all.
but to me it is not hack it is a clever idea that let the programmer to decide what to do at the image side to implement crazy stuff without modifying the VM
That sure is clever and it's great to not have to modify the vm, but modifying it to support proxies worth it in my opinion.
The VM is simple (one interception hook) while it enables to capture a lot of things. Of course we can imagine something else at the VM side but the more code in the VM the less flexible it will be
do you consider DNU as hack too?
Using it to implement proxies? Yes. But in addition, DNU is bad since you can only intercept messages that are not understood. And you can also by-pass the message the proxy does understand by sending directly #doesNotUnderstand: to the proxy with a specific message as argument.
we also explained that in the Ghost paper... that is why cannotInterpret is better but yet incompelete to capture everything
Only because of compilation optimizations. It is a real problem for certain applications.
. To intercept iv access or other events we have to rely on code instrumentation and delegation.
yes but I would like to investigate if cannot achieve iv interception using special slots
I doubt we can since it is the target's slots that are taken into account during compilation. Or else every slot in the system must be special => really poor performances.
I have no clear idea yet on that so I must have look and you are certainly right
Luc
It would be easier if the VM would allow to create an object that controls its own interpretation (via a metaobject that defines a MOP for example). Such an object should at least be able to specify its message lookup and how to reads and writes IVs. And optionally: - how it sends messages this one is possible with cannotInterpret you intercept and then you decide what to do and maybe execute something else so you control message sending
I was talking about interception of message sending (the message the target would have sent) not of interception of message reception (the living wage of any proxy implementation :) ). Like the others events, it also lies at the submethod level.
- how it resolves other variables (temporaries, arguments, globals, class variables) - how it resolves literals - how it executes primitives (because else the VM may cry) - how it is assigned to a variable or passed in a message (to control static/dynamic aliasing respectively)
all of those ones are submethod level and yes Ghost stops at the object granularity currently
- ... many others ... With such objects (+ operating by delegation instead of forwarding) we can solve most of the requirements listed above (well except performant delimited replacement). All that to say that it is not easy...
yes but it is interesting ;-) and we also discuss "some parts" of that with Nick
Great, let us know about the conclusions :)
Luc
(this way we would avoid that everyone creates one that is not completely working)
2014-05-22 13:06 GMT-03:00 Camille Teruel <camille.teruel@gmail.com>:
On 22 mai 2014, at 11:54, stepharo <stepharo@free.fr> wrote:
In general, we should think about if is would make sense that the language comes with a good proxy model by default.
+ 1 We should do that with Camille.
Yes. Now the problem is to agree on what is a "good model". There is many use cases for proxies and they come with their own models and problems. Here are some requirements I can think of:
- Uniformity: all objects can be wrapped, even special ones (it's a technicality but it's still important) - Interception of all message: currently we cannot intercept #== and optimized control-flow messages like #ifTrue:ifFalse #to:do:, #whileTrue:, etc...
- Encapsulation (a.k.a the self problem): avoid leaking of references to the target. E.g. "aProxy yourself" should return the proxy not the target.
Funny thing is that Glorp proxies materialize the referenced object when they receive #yourself
- Behavioral intercession: Not everything is a message send. What other events do we want to intercept? IV access is a must-have for me. - Composition: Wrapping a proxy with another one should work as expected, i.e. applying both policies in order. - Performances: intercepting message sends is slow, intercepting iv accesses is even worse (relying on code instrumentation). We would need VM support. - Security: It shouldn't be possible to by-pass or corrupt a proxy policy.
- Delimited replacement: Ensure that a proxy is always used in place of its target throughout the processing of a message send, no matter the alias used (that is not necessarily "self"). Think about a read-only proxy for example.
One thing is a Proxy that ALWAYS sits in between the real object and its consumer forwarding messages or doing any other instrumentation, and a different thing is a Stub which once materialized replaces all references to the proxy with references to the new object (#becomeForward:) and then vanishes (GCed). Having proxies in hashed collections can get very tricky if the hash of the proxy/stub is different from the hash of the materialized object. Esteban A. Maringolo
2014-05-22 20:37 GMT+02:00 Esteban A. Maringolo <emaringolo@gmail.com>:
2014-05-22 13:06 GMT-03:00 Camille Teruel <camille.teruel@gmail.com>:
On 22 mai 2014, at 11:54, stepharo <stepharo@free.fr> wrote:
In general, we should think about if is would make sense that the
language comes with
a good proxy model by default.
+ 1 We should do that with Camille.
Yes. Now the problem is to agree on what is a "good model". There is many use cases for proxies and they come with their own models and problems. Here are some requirements I can think of:
- Uniformity: all objects can be wrapped, even special ones (it's a technicality but it's still important) - Interception of all message: currently we cannot intercept #== and optimized control-flow messages like #ifTrue:ifFalse #to:do:, #whileTrue:, etc...
- Encapsulation (a.k.a the self problem): avoid leaking of references to the target. E.g. "aProxy yourself" should return the proxy not the target.
Funny thing is that Glorp proxies materialize the referenced object when they receive #yourself
- Behavioral intercession: Not everything is a message send. What other events do we want to intercept? IV access is a must-have for me. - Composition: Wrapping a proxy with another one should work as expected, i.e. applying both policies in order. - Performances: intercepting message sends is slow, intercepting iv accesses is even worse (relying on code instrumentation). We would need VM support. - Security: It shouldn't be possible to by-pass or corrupt a proxy policy.
- Delimited replacement: Ensure that a proxy is always used in place of its target throughout the processing of a message send, no matter the alias used (that is not necessarily "self"). Think about a read-only proxy for example.
One thing is a Proxy that ALWAYS sits in between the real object and its consumer forwarding messages or doing any other instrumentation, and a different thing is a Stub which once materialized replaces all references to the proxy with references to the new object (#becomeForward:) and then vanishes (GCed).
Having proxies in hashed collections can get very tricky if the hash of the proxy/stub is different from the hash of the materialized object.
yes exactly That is why in Ghost, you can choose what to intercept because it is application dependent Luc
Esteban A. Maringolo
participants (6)
-
Camille Teruel -
Esteban A. Maringolo -
François Stephany -
Luc Fabresse -
Marcus Denker -
stepharo