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

Juan Vuletich JuanVuletich at zoho.com
Tue Mar 7 12:49:53 UTC 2017


Hi Dave,

Thanks for answering. Inline.

On 3/6/2017 10:50 PM, David T. Lewis wrote:
>
> In the VM, the millisecond clock wraps within the 32 bit integer range:
>
>    #define MillisecondClockMask 0x1FFFFFFF
>
> In the Cuis image, Delay class>>handleTimerEvent does this:
>
>    nextTick := nextTick min: SmallInteger maxVal.
>
> On a 64-bit Spur image, SmallInteger maxVal is 16rFFFFFFFFFFFFFFF, but on
> a 32-bit image it is 16r3FFFFFFF.
>
> Could that be it?

I wasn't aware of that, and had assumed that millisecond timer would use 
the whole SmallInteger range. This might introduce a bug, that would 
only appear at timer rollover, i.e. about 6 days after image startup. 
I'll fix this. Thanks.

But this is a completely separated issue. The problem we saw, the 
semaphore never being signaled if deadline is in the past, happens 
immediately after image startup.

> I don't really know how to test in Squeak. As you say, Squeak is now
> using the microsecond clock in #handleTimerEvent. I do not see anything
> in primitiveSignalAtMilliseconds that would behave any differently on
> a 64 bit versus 32 bit image or VM, but I do not know how to test to
> be sure.
>
> Dave

Well, what follows is a way to test VM behavior. Tested in Cuis, but 
should be trivial to reproduce in Squeak, as it is a VM issue. I Cuis 
add (copied from Squeak):

!Time class methodsFor: 'general inquiries' stamp: 'jmv 3/7/2017 08:58:12'!
utcMicrosecondClock
     "Answer the UTC microseconds since the Smalltalk epoch (January 1st 
1901, the start of the 20th century).
      The value is derived from the Posix epoch with a constant offset 
corresponding to elapsed microseconds
      between the two epochs according to RFC 868."
<primitive: 240>
     ^0! !

!Delay class methodsFor: 'primitives' stamp: 'jmv 3/7/2017 08:57:45'!
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! !

Then, in a Workspace, try the following 4 doits:

s _ Semaphore new.
Delay primSignal: s atUTCMicroseconds: Time utcMicrosecondClock + 10.
s wait.
'Ok' print.

s _ Semaphore new.
Delay primSignal: s atMilliseconds: Time millisecondClockValue + 10.
s wait.
'Ok' print.

s _ Semaphore new.
Delay primSignal: s atUTCMicroseconds: Time utcMicrosecondClock - 10.
s wait.
'Ok' print.

s _ Semaphore new.
Delay primSignal: s atMilliseconds: Time millisecondClockValue - 10.
s wait.
'Not OK at all' print.

On Spur32, all 4 finish immediately. On Spur64, the first 3 also finish 
immediately, but the fourth freezes the image. The difference in 
behavior between Spur32 and Spur64 (on Linux) is indeed there.


Ok. Also tried Squeak (note that instead of #millisecondClockValue in 
Squeak it is #primMillisecondClock) :

s _ Semaphore new.
Delay primSignal: s atUTCMicroseconds: Time utcMicrosecondClock + 10.
s wait.
'Ok'.

s _ Semaphore new.
Delay primSignal: s atMilliseconds: Time primMillisecondClock + 10.
s wait.
'Ok'.

s _ Semaphore new.
Delay primSignal: s atUTCMicroseconds: Time utcMicrosecondClock - 10.
s wait.
'Ok'.

s _ Semaphore new.
Delay primSignal: s atMilliseconds: Time primMillisecondClock - 10.
s wait.
'Not OK at all'.

Exactly the same behavior.

I just took a look at
static void primitiveSignalAtMilliseconds(void)
in 
https://raw.githubusercontent.com/OpenSmalltalk/opensmalltalk-vm/Cog/src/vm/cointerp.c
The only thing I see is that msecs is an usqInt and deltaMsecs is an 
sqInt. But I'm not good enough at gcc subtleties to say if this matters 
at all. I mean, it looks as if  'if (deltaMsecs < 0) {' was true on 
Spur64 and false on Spur32... Or maybe the difference is in the handling 
of nextWakeupUsecs ...

In any case, it looks like deadlines in the past are not supported (as 
code assumes they are because of rollover...)

Thanks,

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
@JuanVuletich




More information about the Vm-dev mailing list