[Vm-dev] We need help from VM experts. Re: Freeze after Morph& nbsp; & nbsp; & nbsp; & nbsp; Activity

Eliot Miranda eliot.miranda at gmail.com
Thu Mar 9 20:25:53 UTC 2017


Hi Juan, Hi All,



On Mon, Mar 6, 2017 at 6:06 AM, Juan Vuletich <JuanVuletich at zoho.com> wrote:

>
> I finally understood what was happening. The problem with is primitive 136:
>
> primSignal: aSemaphore atMilliseconds: aSmallInteger
>     "Signal the semaphore when the millisecond clock reaches the value of
> the second argument. Fail if the first argument is neither a Semaphore nor
> nil. Essential. See Object documentation whatIsAPrimitive."
>     <primitive: 136>
>     ^self primitiveFailed
>

Yes, but primitive 136 *should not be used* :-).  You should use primitive
242:
primSignal: aSemaphore atUTCMicroseconds: anInteger
"Signal the semaphore when the UTC microsecond clock reaches the value of
the second argument.
Fail if the first argument is neither a Semaphore nor nil, or if the second
argument is not an integer.
Essential. See Object documentation whatIsAPrimitive."
<primitive: 242>
^self primitiveFailed

The use of the UTC microsecond count eliminates any and all wrapping issues
for about 50,000 years [puhleaze Mr Pruitt can you try and do your bit to
make it possible that we'll make it that far. hic. ed.].  The old primitive
136 primSignal:atMilliseconds: is subject to wrapping problems.  I see that
primSignal:atMilliseconds: is still used in Squeak 5.x but only to turn off
signaling:

Delay class>>shutDown
"Suspend the active delay, if any, before snapshotting. It will be
reactived when the snapshot is resumed."
"Details: This prevents a timer interrupt from waking up the active delay
in the midst snapshoting, since the active delay will be restarted when
resuming the snapshot and we don't want to process the delay twice."

AccessProtect wait.
self primSignal: nil atMilliseconds: 0.
self saveResumptionTimes.
DelaySuspended := true.

Delay class>>stopTimerInterruptWatcher
"Reset the class variables that keep track of active Delays and re-start
the timer interrupt watcher process. Any currently scheduled delays are
forgotten."
"Delay startTimerInterruptWatcher"
self primSignal: nil atMilliseconds: 0.
TimingSemaphore ifNotNil:[TimingSemaphore terminateProcess].

I will change this now.


HTH


> If the requested tick is already in the past, all the VMs except for
> Spur-64 will signal the semaphore anyway. Spur-64 won't. Taking care of
> this in the Cuis image was easy enough.
>
> Squeak seems not to be affected because it uses a newer primitive, that
> takes the large integer microsecond ticker, that might have the older
> behavior (signaling anyway). I'm not really sure, and maybe someone could
> check the primitive behavior and the corresponding assumptions in Squeak.
>
> Older Squeak images are not affected, as they are all 32-bit. So maybe
> there's no action required. In any case, making the behavior consistent
> across VMs and in both primitives would be nice.
>
> Cheers,
>
> On 3/3/2017 3:55 PM, Juan Vuletich wrote:
>
>
>
> Hi Folks,
>
> Today, I was able to get closer to the origin of the problem. The problem
> is when Morphic tries to do a Delay (inter-cycle-pause) of 1 or two
> milliseconds. (Usually they are quite larger, and the problem does not
> appear). With the 64-bit VM, sometimes very short delays hang the complete
> system. I don't know why, but this:
>
> waitDelay _ Delay forMilliseconds: 50.
> [ true ] whileTrue: [
>     1000 atRandom print.
>     waitDelay setDelay: 1; wait ].
>
> is enough to hang Cuis in a short time. When trying to reproduce the
> problem in Squeak I had mixed results. It doesn't seem to hang there, but
> if I let this run for a couple of minutes and then try to halt with alt-. ,
> then the hang occurs, and Squeak becomes irresponsibe. As a workaround, in
> Cuis in the inter cycle pause, I'm avoiding very short delays.
>
> I'm not sure if the bug is in the VM, in  the image, or both, but it is
> still there, and it also affects Squeak. I haven't tried it, but Pharo
> might also have the problem (if not, it can show a possible solution).
>
> BTW, Bert, I guess Squeak never does short delays in #interCyclePause: ...
>
> Thanks,
>
> On 2/6/2017 12:28 PM, Bert Freudenberg wrote:
>
>
>
> Yes, I tried with Spur64. Have not seen it freeze yet on Mac in Squeak,
> but we possibly have not replicated the test well enough yet.
>
> It *did* freeze in Cuis Spur64 on Mac too.
>
> - Bert -
>
> On Mon, Feb 6, 2017 at 2:08 PM, Juan Vuletich <juanvuletich at zoho.com>
> wrote:
>
>>
>> Were you usig Spur64? On Debian it does not freeze with CogV3 or Spur32.
>> Only with Spur64.
>>
>> Thanks,
>> Juan
>>
>> Sent using Zoho Mail <https://www.zoho.com/mail/>
>>
>>
>> ---- On Mon, 06 Feb 2017 09:19:48 -0300 * bert at freudenbergs.de
>> <bert at freudenbergs.de> * wrote ----
>>
>> On Mon, Feb 6, 2017 at 3:15 AM, David T. Lewis <lewis at mail.msen.com>
>> wrote:
>>
>> It would be interesting to try reproducing this in a Squeak image, but I
>> have not quite figured out how to make the Tokenish example work in
>> Squeak.
>>
>>
>> See attachment. Did not freeze on Mac with 10 Tokenish jumping.
>> - Bert -
>>
>>
>>
>>
>
>
> --
> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> @JuanVuletich
>
>
>
> --
> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> @JuanVuletich
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170309/881f29a9/attachment-0001.html>


More information about the Vm-dev mailing list