[Vm-dev] Explicitly avoiding process switch

[stephane ducasse]

On Aug 11, 2011, at 5:10 PM, Igor Stasenko wrote:

> 
> 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.

yes this us my favorite solution :)

> 
> 
>> 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.