[Vm-dev] Explicitly avoiding process switch

Igor Stasenko siguctua at gmail.com
Thu Aug 11 15:10:32 UTC 2011


On 11 August 2011 16:28, stephane ducasse <stephane.ducasse at gmail.com> wrote:
>
> One idea marcus mentioned was to have an explicit bytecode for suspension point.
> I think that explicit semantics and behavior is always better.
>
> Marcus is also thinking about expression or method tagging that the compiler could take into account
> to generate this specific bytecode.
>

We're discussed this today.
My own point that we should design our algorithms to never rely on
some specific scheduling semantics,
but always assume that an interrupt could happen at any moment, or
more in general:
two or more processes could run in parallel.

Because if you won't let baby to start walking and running (and of
course there are 90% risk of falling down at the beginning),
by tying it tightly in baby carriage, one have zero chances to learn
how to walk without falling down.


> Stef
>
>
>>
>> I would properly comment the places where this "ATOMIC" operation is
>> really used.
>>
>> Nicolas
>>
>> 2011/8/11 Mariano Martinez Peck <marianopeck at gmail.com>:
>>>
>>> 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
>>>
>>>
>>>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list