[Vm-dev] Explicitly avoiding process switch

[Igor Stasenko]

On 11 August 2011 13:17, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
>
> I would properly comment the places where this "ATOMIC" operation is
> really used.

Like in
AtomicQueueItem>>makeCircular? :)


I also remember discussion that some precautions in code to not insert
suspension point(s) in ProcessorScheduler/Process/or Semaphore..
but i forgot which one exactly.
Is it LinkedList>>removeLink:?


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