[Vm-dev] Explicitly avoiding process switch

Mariano Martinez Peck marianopeck at gmail.com
Thu Aug 11 10:32:47 UTC 2011


Hi guys. We were discussing yesterday with Marcus about the following....

 I remember a problem we have in Pharo because of changing "foo == nil" to
"foo isNil"  in some important places like Process/Delay/Semaphore. Such
change introduces a suspension point, where if I understand correctly, the
scheduler can switch to another process only during method sends. #== is
optimized with a special bytecode and there is no message send. Sending
#isNil is a message sent, and hence we introduce a suspension point. In 99%
of the cases this is not a problem.  But I can imagine that there are places
(mostly those related to Process/Delay/Semaphore) where this changes can be
very very bad.


To do some experiments, I want to remove the bytecode for #== but of course,
I think I will have all these problems. And there are more. Marcus told me
that some optimizations done by the compiler end up sending #==. And I also
remember some code he told me (I think it was #allObjectsDo:) that would
never finish because of the block closure objects creation.

So...what about making the necessity of NOT sending a message or NOT
introducing a suspension point more explicit?  first we should have the
support for that and second know each place where we need them.

The most basic thing I can think of is doing something like:

(ParseNode classVarNamed:  'StdSelectors') at: #== put:
#bytecodedEqualEqual.
Compiler recompileAll.

And put a nice comment why one may want to use #optimizedEqualEqual. But
again, in which places should I change #== for #bytecodedEqualEqual


Any thought or idea about them is really appreciated.

Thanks


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110811/6f3867fd/attachment.htm


More information about the Vm-dev mailing list