show bytecodes?
Robert Withers
reefedjib at yahoo.com
Mon Oct 15 22:55:42 UTC 2007
Hi Nicolas,
On Oct 15, 2007, at 3:25 PM, nicolas cellier wrote:
>
> Doing this, you will inline code until the viral #eventual message
> has contaminated every other message receiver.
> Risk is to end up with huge unmanageable expressions.
It's true that it seems that an eventual ref will contaminate method
contexts and objects which come into contact with the eventual ref
and that that could spread to all references and activations within a
process. While I haven't thought through this viral aspect that
deeply, my hope is that some way could be found to inoculate as fast
as they get contaminated or otherwise limit how much gets contaminated.
> You don't have to develop all possible branches... #ifTrue:ifFalse:
> would result in an EventualMessageSend with 5 eventual as receiver
> and some blocks as argument, once you know how to recompile with
> optimization off (You should also consider NewCompiler for
> compiling blocks...).
Yes, but one or both of these blocks (both in the example given) may
have a return statement, which would return from the method context
that called ifTrue:ifFalse:. So I am thinking that context needs to
be infected as an eventual context and generate a promise:resolver
pair such that an internal return, like the one in the block above or
the one at the end, would resolve the promise. Also, all statements
in the context would need to be eventually sent, and all refs would
need to become eventual, to maintain msg ordering. I think.
>
> Shouldn't you concentrate on resolving the promise as a kind of
> message send at highest level possible, like (4 + 5 eventual)
> resolve in (EventualSend receiver: 4 message: #+ argument: 5
> eventual)?
Yes, but you have already made it viral by making the #+ be sent
eventually. What I am saying instead is making that happen from
inside the implementation of #+, and it is occurring because inside
of that implementation is is sending ifTrue:ifFalse: which is a
primitive/bytecodePrim. Not making normal activations eventual, but
just activations that contain a primitive call, was a way I was
planning to limit the viral nature. Your point about full
contamination may trump this hope.
>
> That's however quite a challenge...
> Maybe an ExceptionHandler trapping the Eventual>>doesNotUnderstand
> to backtrack thisContext stack while an eventual argument has been
> passed...
That's an interesting idea. Then we would be explicitly infecting
all contexts on the stack, but perhaps it could be done without much
VM work. I still need to get ifTrue: and friends (and possibly
others like #whileTrue:) to normalSend their selectors if they fail,
so I can intercept the msg send and make it eventual. Then we can
start playing with it.
Cheers,
Rob
More information about the Squeak-dev
mailing list
|