Add primitiveMillisecondClockMask? (was: The Trunk: Kernel-ar.564.mcz)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Add primitiveMillisecondClockMask? (was: The Trunk: Kernel-ar.564.mcz)

David T. Lewis
 
On Thu, Apr 07, 2011 at 09:04:41AM +0000, [hidden email] wrote:

>
> Andreas Raab uploaded a new version of Kernel to project The Trunk:
> http://source.squeak.org/trunk/Kernel-ar.564.mcz
>
> ==================== Summary ====================
>
> Name: Kernel-ar.564
> Author: ar
> Time: 7 April 2011, 11:04:21.248 am
> UUID: 32ecb9c9-177a-ce45-9c1c-a3714c801929
> Ancestors: Kernel-nice.563
>
> Fix computation of Time>>milliseconds:since: which would compute incorrect deltas upon clock overflow.
>
> =============== Diff against Kernel-nice.563 ===============
>
> Item was added:
> + ----- Method: Time class>>millisecondClockMask (in category 'general inquiries') -----
> + millisecondClockMask
> + "The VM mask for the max. millisecond clock value.
> + This should be primitive but it ain't so it's copied inline from the Interpreter."
> + ^16r1FFFFFFF!
>

Agreed, the millisecondClockMask should be available from a primitive.
Should I make it so?

Dave

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Add primitiveMillisecondClockMask? (was: The Trunk: Kernel-ar.564.mcz)

David T. Lewis
 
On Wed, Apr 13, 2011 at 11:57:32AM -0700, Eliot Miranda wrote:

> On Wed, Apr 13, 2011 at 11:09 AM, David T. Lewis <[hidden email]>wrote:
>
> > On Thu, Apr 07, 2011 at 09:04:41AM +0000, [hidden email] wrote:
> > >
> > > Andreas Raab uploaded a new version of Kernel to project The Trunk:
> > > http://source.squeak.org/trunk/Kernel-ar.564.mcz
> > >
> > > ==================== Summary ====================
> > >
> > > Name: Kernel-ar.564
> > > Author: ar
> > > Time: 7 April 2011, 11:04:21.248 am
> > > UUID: 32ecb9c9-177a-ce45-9c1c-a3714c801929
> > > Ancestors: Kernel-nice.563
> > >
> > > Fix computation of Time>>milliseconds:since: which would compute
> > incorrect deltas upon clock overflow.
> > >
> > > =============== Diff against Kernel-nice.563 ===============
> > >
> > > Item was added:
> > > + ----- Method: Time class>>millisecondClockMask (in category 'general
> > inquiries') -----
> > > + millisecondClockMask
> > > +     "The VM mask for the max. millisecond clock value.
> > > +     This should be primitive but it ain't so it's copied inline from
> > the Interpreter."
> > > +      ^16r1FFFFFFF!
> > >
> >
> > Agreed, the millisecondClockMask should be available from a primitive.
> > Should I make it so?
> >
>
> Personally I would much rather see us move to the 64-bit millisecond clock I
> implemented for Cog. This renders the whole clock roll-over issue moot.
>

Understood, though my question was intended to be about the existing
primitiveMillisecondClock, which will presumably be retained for a
few more years. Andreas committed a fix for a rather nasty bug related
to a constant in the image being out of sync with a constant in the VM.
The method comment noted that "This should be primitive but it ain't"
so I was just offering to add the primitive and update Squeak trunk
to use it when available.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Add primitiveMillisecondClockMask? (was: The Trunk: Kernel-ar.564.mcz)

David T. Lewis
 
On Wed, Apr 13, 2011 at 07:07:57PM -0700, Colin Putney wrote:

> On Wed, Apr 13, 2011 at 6:58 PM, David T. Lewis <[hidden email]> wrote:
>
> > Understood, though my question was intended to be about the existing
> > primitiveMillisecondClock, which will presumably be retained for a
> > few more years. Andreas committed a fix for a rather nasty bug related
> > to a constant in the image being out of sync with a constant in the VM.
> > The method comment noted that "This should be primitive but it ain't"
> > so I was just offering to add the primitive and update Squeak trunk
> > to use it when available.
>
> Why does the existing primitiveMillisecondClock have to be maintained?
> Is there a lot of code that depends on it rolling over? No sarcasm
> intended, it's an honest question.

It is used by Time class>>millisecondClockValue, so see senders of
#millisecondClockValue.

>From the point of view of the VM, the primitive needs to be maintained
because many existing images expect it to be there. From the point of
view of the image, a different and better implementation can easily
be adopted. My question was from the point of view of the VM, if we
assume that many images will expect primitiveMillisecondClock to be
there, should we also add primitiveMillisecondClockMask such that
those images can obtain the correct mask value if they choose to
do so (both the VM and the image changes are minor updates).

With respect to code that depends on the clock rollover, I expect
that the most serious concern would related to socket timeouts, which
might intermittently affect server applications, Seaside, etc.

To be clear, the patch that Andreas committed will fully address
the problem for all current VMs and images, so this discussion
has little or no practical impact. It's really just about tidying
up some loose ends just in case the the primitiveMillisecondClock
ends up getting used for a few years longer than any of us might
care to anticipate ;)

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Add primitiveMillisecondClockMask?

Andreas.Raab
In reply to this post by David T. Lewis
 


On 4/13/2011 20:09, David T. Lewis wrote:
> Agreed, the millisecondClockMask should be available from a primitive.
> Should I make it so?

Sure. I would do it via a vm attribute.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Add primitiveMillisecondClockMask? (was: The Trunk: Kernel-ar.564.mcz)

Bert Freudenberg
In reply to this post by David T. Lewis


On 14.04.2011, at 04:46, David T. Lewis wrote:

>
> On Wed, Apr 13, 2011 at 07:07:57PM -0700, Colin Putney wrote:
>> On Wed, Apr 13, 2011 at 6:58 PM, David T. Lewis <[hidden email]> wrote:
>>
>>> Understood, though my question was intended to be about the existing
>>> primitiveMillisecondClock, which will presumably be retained for a
>>> few more years. Andreas committed a fix for a rather nasty bug related
>>> to a constant in the image being out of sync with a constant in the VM.
>>> The method comment noted that "This should be primitive but it ain't"
>>> so I was just offering to add the primitive and update Squeak trunk
>>> to use it when available.
>>
>> Why does the existing primitiveMillisecondClock have to be maintained?
>> Is there a lot of code that depends on it rolling over? No sarcasm
>> intended, it's an honest question.
>
> It is used by Time class>>millisecondClockValue, so see senders of
> #millisecondClockValue.
>
>> From the point of view of the VM, the primitive needs to be maintained
> because many existing images expect it to be there. From the point of
> view of the image, a different and better implementation can easily
> be adopted. My question was from the point of view of the VM, if we
> assume that many images will expect primitiveMillisecondClock to be
> there, should we also add primitiveMillisecondClockMask such that
> those images can obtain the correct mask value if they choose to
> do so (both the VM and the image changes are minor updates).
>
> With respect to code that depends on the clock rollover, I expect
> that the most serious concern would related to socket timeouts, which
> might intermittently affect server applications, Seaside, etc.
>
> To be clear, the patch that Andreas committed will fully address
> the problem for all current VMs and images, so this discussion
> has little or no practical impact. It's really just about tidying
> up some loose ends just in case the the primitiveMillisecondClock
> ends up getting used for a few years longer than any of us might
> care to anticipate ;)
>
> Dave

I agree that it should have been made a primitive long ago. However, adding it now would only make sense if we anticipate that it will ever change. And since Eliot is advocating to switch over to a 64 bit clock anyway, what's the point of changing the old one now?

I'd still retain the old primitive for accessing millisecondClockValue because it certainly can be cheaper (no LargeInts). Or was there a proposal to actually change the old primitive, instead of adding the high-res one?

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: Add primitiveMillisecondClockMask?

David T. Lewis
In reply to this post by Andreas.Raab
 
On Thu, Apr 14, 2011 at 11:27:48AM +0200, Andreas Raab wrote:

>
>
>
> On 4/13/2011 20:09, David T. Lewis wrote:
> >Agreed, the millisecondClockMask should be available from a primitive.
> >Should I make it so?
>
> Sure. I would do it via a vm attribute.
>
> Cheers,
>   - Andreas

The named primitive is trivial, so I think this is probably the simplest
thing to do:

primitiveMillisecondClockMask
        "Provide access to the millisecond clock mask to support calculation
        of durations based on the millisecond clock value."

        <export: true>
        self pop: 1 thenPush: (self integerObjectOf: MillisecondClockMask)

On the image side, call the primitive at #startUp: time, save the
value in a class variable for speed, and use the default 16r1FFFFFFF
if the primitive is not present.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Add primitiveMillisecondClockMask?

Andreas.Raab
 
On 4/14/2011 13:21, David T. Lewis wrote:

>
> On Thu, Apr 14, 2011 at 11:27:48AM +0200, Andreas Raab wrote:
>>
>>
>> On 4/13/2011 20:09, David T. Lewis wrote:
>>> Agreed, the millisecondClockMask should be available from a primitive.
>>> Should I make it so?
>> Sure. I would do it via a vm attribute.
>>
>> Cheers,
>>    - Andreas
> The named primitive is trivial, so I think this is probably the simplest
> thing to do:
>
> primitiveMillisecondClockMask
> "Provide access to the millisecond clock mask to support calculation
> of durations based on the millisecond clock value."
>
> <export: true>
> self pop: 1 thenPush: (self integerObjectOf: MillisecondClockMask)
>
> On the image side, call the primitive at #startUp: time, save the
> value in a class variable for speed, and use the default 16r1FFFFFFF
> if the primitive is not present.

You're right. It also makes it easier to remove the primitive later
(i.e., the change is completely self-contained).

Cheers,
   - Andreas


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Add primitiveMillisecondClockMask? (was: The Trunk: Kernel-ar.564.mcz)

Eliot Miranda-2
In reply to this post by Bert Freudenberg
 


On Thu, Apr 14, 2011 at 3:23 AM, Bert Freudenberg <[hidden email]> wrote:


On 14.04.2011, at 04:46, David T. Lewis wrote:

>
> On Wed, Apr 13, 2011 at 07:07:57PM -0700, Colin Putney wrote:
>> On Wed, Apr 13, 2011 at 6:58 PM, David T. Lewis <[hidden email]> wrote:
>>
>>> Understood, though my question was intended to be about the existing
>>> primitiveMillisecondClock, which will presumably be retained for a
>>> few more years. Andreas committed a fix for a rather nasty bug related
>>> to a constant in the image being out of sync with a constant in the VM.
>>> The method comment noted that "This should be primitive but it ain't"
>>> so I was just offering to add the primitive and update Squeak trunk
>>> to use it when available.
>>
>> Why does the existing primitiveMillisecondClock have to be maintained?
>> Is there a lot of code that depends on it rolling over? No sarcasm
>> intended, it's an honest question.
>
> It is used by Time class>>millisecondClockValue, so see senders of
> #millisecondClockValue.
>
>> From the point of view of the VM, the primitive needs to be maintained
> because many existing images expect it to be there. From the point of
> view of the image, a different and better implementation can easily
> be adopted. My question was from the point of view of the VM, if we
> assume that many images will expect primitiveMillisecondClock to be
> there, should we also add primitiveMillisecondClockMask such that
> those images can obtain the correct mask value if they choose to
> do so (both the VM and the image changes are minor updates).
>
> With respect to code that depends on the clock rollover, I expect
> that the most serious concern would related to socket timeouts, which
> might intermittently affect server applications, Seaside, etc.
>
> To be clear, the patch that Andreas committed will fully address
> the problem for all current VMs and images, so this discussion
> has little or no practical impact. It's really just about tidying
> up some loose ends just in case the the primitiveMillisecondClock
> ends up getting used for a few years longer than any of us might
> care to anticipate ;)
>
> Dave

I agree that it should have been made a primitive long ago. However, adding it now would only make sense if we anticipate that it will ever change. And since Eliot is advocating to switch over to a 64 bit clock anyway, what's the point of changing the old one now?

I'd still retain the old primitive for accessing millisecondClockValue because it certainly can be cheaper (no LargeInts). Or was there a proposal to actually change the old primitive, instead of adding the high-res one?

I've heard this argument advanced (that the old interface is cheaper because of no large integers) but I think it's largely a straw man.  If you consider the simplicities that accrue from using a 64-bit clock that can't wrap and is synchronised to wall time (i.e. that Time now is derived from those same microseconds) then it's reasonable to assume the large int allocation cost will be substantially if not entirely recouped by simplicities higher up in Time, Delay et al.  No, I don't have figures; only experience with VW where we didn't notice any degradation but did loose a number of painful 45 1/2 day bugs.

Eliot


- Bert -



Reply | Threaded
Open this post in threaded view
|

Re: Add primitiveMillisecondClockMask?

Eliot Miranda-2
In reply to this post by Andreas.Raab
 


On Thu, Apr 14, 2011 at 5:39 AM, Andreas Raab <[hidden email]> wrote:

On 4/14/2011 13:21, David T. Lewis wrote:

On Thu, Apr 14, 2011 at 11:27:48AM +0200, Andreas Raab wrote:


On 4/13/2011 20:09, David T. Lewis wrote:
Agreed, the millisecondClockMask should be available from a primitive.
Should I make it so?
Sure. I would do it via a vm attribute.

Cheers,
  - Andreas
The named primitive is trivial, so I think this is probably the simplest
thing to do:

primitiveMillisecondClockMask
       "Provide access to the millisecond clock mask to support calculation
       of durations based on the millisecond clock value."

       <export: true>
       self pop: 1 thenPush: (self integerObjectOf: MillisecondClockMask)

On the image side, call the primitive at #startUp: time, save the
value in a class variable for speed, and use the default 16r1FFFFFFF
if the primitive is not present.

You're right. It also makes it easier to remove the primitive later (i.e., the change is completely self-contained).

+1
 

Cheers,
 - Andreas



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Add primitiveMillisecondClockMask? (was: The Trunk: Kernel-ar.564.mcz)

Bert Freudenberg
In reply to this post by Eliot Miranda-2
 

On 14.04.2011, at 20:56, Eliot Miranda wrote:



On Thu, Apr 14, 2011 at 3:23 AM, Bert Freudenberg <[hidden email]> wrote:


On 14.04.2011, at 04:46, David T. Lewis wrote:

>
> On Wed, Apr 13, 2011 at 07:07:57PM -0700, Colin Putney wrote:
>> On Wed, Apr 13, 2011 at 6:58 PM, David T. Lewis <[hidden email]> wrote:
>>
>>> Understood, though my question was intended to be about the existing
>>> primitiveMillisecondClock, which will presumably be retained for a
>>> few more years. Andreas committed a fix for a rather nasty bug related
>>> to a constant in the image being out of sync with a constant in the VM.
>>> The method comment noted that "This should be primitive but it ain't"
>>> so I was just offering to add the primitive and update Squeak trunk
>>> to use it when available.
>>
>> Why does the existing primitiveMillisecondClock have to be maintained?
>> Is there a lot of code that depends on it rolling over? No sarcasm
>> intended, it's an honest question.
>
> It is used by Time class>>millisecondClockValue, so see senders of
> #millisecondClockValue.
>
>> From the point of view of the VM, the primitive needs to be maintained
> because many existing images expect it to be there. From the point of
> view of the image, a different and better implementation can easily
> be adopted. My question was from the point of view of the VM, if we
> assume that many images will expect primitiveMillisecondClock to be
> there, should we also add primitiveMillisecondClockMask such that
> those images can obtain the correct mask value if they choose to
> do so (both the VM and the image changes are minor updates).
>
> With respect to code that depends on the clock rollover, I expect
> that the most serious concern would related to socket timeouts, which
> might intermittently affect server applications, Seaside, etc.
>
> To be clear, the patch that Andreas committed will fully address
> the problem for all current VMs and images, so this discussion
> has little or no practical impact. It's really just about tidying
> up some loose ends just in case the the primitiveMillisecondClock
> ends up getting used for a few years longer than any of us might
> care to anticipate ;)
>
> Dave

I agree that it should have been made a primitive long ago. However, adding it now would only make sense if we anticipate that it will ever change. And since Eliot is advocating to switch over to a 64 bit clock anyway, what's the point of changing the old one now?

I'd still retain the old primitive for accessing millisecondClockValue because it certainly can be cheaper (no LargeInts). Or was there a proposal to actually change the old primitive, instead of adding the high-res one?

I've heard this argument advanced (that the old interface is cheaper because of no large integers) but I think it's largely a straw man.  If you consider the simplicities that accrue from using a 64-bit clock that can't wrap and is synchronised to wall time (i.e. that Time now is derived from those same microseconds) then it's reasonable to assume the large int allocation cost will be substantially if not entirely recouped by simplicities higher up in Time, Delay et al.  No, I don't have figures; only experience with VW where we didn't notice any degradation but did loose a number of painful 45 1/2 day bugs.

Eliot

I don't disagree, in particular with running on Cog which is much more comparable to VW than the interpreter. But what speaks against retaining the old primitive even if it is unused in modern images?

So do you propose to add the primitiveMillisecondClockMask primitive in anticipation of changing primitiveMillisecondClock to answer an absolute time?

In light of what Igor reported I'd think that having the time be monotonically increasing is quite valuable, too. Or do we need to have in-image logic to catch the clock jumping backwards?

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Add primitiveMillisecondClockMask? (was: The Trunk: Kernel-ar.564.mcz)

Eliot Miranda-2
 


On Sat, Apr 16, 2011 at 9:29 AM, Bert Freudenberg <[hidden email]> wrote:
 

On 14.04.2011, at 20:56, Eliot Miranda wrote:



On Thu, Apr 14, 2011 at 3:23 AM, Bert Freudenberg <[hidden email]> wrote:


On 14.04.2011, at 04:46, David T. Lewis wrote:

>
> On Wed, Apr 13, 2011 at 07:07:57PM -0700, Colin Putney wrote:
>> On Wed, Apr 13, 2011 at 6:58 PM, David T. Lewis <[hidden email]> wrote:
>>
>>> Understood, though my question was intended to be about the existing
>>> primitiveMillisecondClock, which will presumably be retained for a
>>> few more years. Andreas committed a fix for a rather nasty bug related
>>> to a constant in the image being out of sync with a constant in the VM.
>>> The method comment noted that "This should be primitive but it ain't"
>>> so I was just offering to add the primitive and update Squeak trunk
>>> to use it when available.
>>
>> Why does the existing primitiveMillisecondClock have to be maintained?
>> Is there a lot of code that depends on it rolling over? No sarcasm
>> intended, it's an honest question.
>
> It is used by Time class>>millisecondClockValue, so see senders of
> #millisecondClockValue.
>
>> From the point of view of the VM, the primitive needs to be maintained
> because many existing images expect it to be there. From the point of
> view of the image, a different and better implementation can easily
> be adopted. My question was from the point of view of the VM, if we
> assume that many images will expect primitiveMillisecondClock to be
> there, should we also add primitiveMillisecondClockMask such that
> those images can obtain the correct mask value if they choose to
> do so (both the VM and the image changes are minor updates).
>
> With respect to code that depends on the clock rollover, I expect
> that the most serious concern would related to socket timeouts, which
> might intermittently affect server applications, Seaside, etc.
>
> To be clear, the patch that Andreas committed will fully address
> the problem for all current VMs and images, so this discussion
> has little or no practical impact. It's really just about tidying
> up some loose ends just in case the the primitiveMillisecondClock
> ends up getting used for a few years longer than any of us might
> care to anticipate ;)
>
> Dave

I agree that it should have been made a primitive long ago. However, adding it now would only make sense if we anticipate that it will ever change. And since Eliot is advocating to switch over to a 64 bit clock anyway, what's the point of changing the old one now?

I'd still retain the old primitive for accessing millisecondClockValue because it certainly can be cheaper (no LargeInts). Or was there a proposal to actually change the old primitive, instead of adding the high-res one?

I've heard this argument advanced (that the old interface is cheaper because of no large integers) but I think it's largely a straw man.  If you consider the simplicities that accrue from using a 64-bit clock that can't wrap and is synchronised to wall time (i.e. that Time now is derived from those same microseconds) then it's reasonable to assume the large int allocation cost will be substantially if not entirely recouped by simplicities higher up in Time, Delay et al.  No, I don't have figures; only experience with VW where we didn't notice any degradation but did loose a number of painful 45 1/2 day bugs.

Eliot

I don't disagree, in particular with running on Cog which is much more comparable to VW than the interpreter. But what speaks against retaining the old primitive even if it is unused in modern images?

Nothing.  I just ant to get us onto a good time basis, and I need to stop blathering and do something :)

 
So do you propose to add the primitiveMillisecondClockMask primitive in anticipation of changing primitiveMillisecondClock to answer an absolute time?

I wouldn't do that.  In Cog (and these can be added to Interpreter) there are separate primitives that answer UTC and local microseconds since 1901.  The old wrapping milliseconds is still available from the old primitive but implemented by truncating the 64-bit microseconds (IIRC after subtracting the start time)
 

In light of what Igor reported I'd think that having the time be monotonically increasing is quite valuable, too. Or do we need to have in-image logic to catch the clock jumping backwards?

We had a discussion a few months ago about the right way to handle this in the VM, i.e that the VM assumes that jumps of the order of a few minutes are clock adjustments, not drift. I need to implement this and test against adjusting the clock backwards.  How Delay copes with clock adjustments is another issue, both for durations and absolute deadlines.  What's a reasonable trade-off between implementation feasibility, desired semantics and sanity?  Right now Delay provides only durations (seems fine to me) but under the covers this gets turned into a deadline.  What happens to a duration (and under the covers to a deadline) when the clock is adjusted?


- Bert -




Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Add primitiveMillisecondClockMask? (was: The Trunk: Kernel-ar.564.mcz)

Igor Stasenko

On 16 April 2011 18:41, Eliot Miranda <[hidden email]> wrote:

>
>
>
> On Sat, Apr 16, 2011 at 9:29 AM, Bert Freudenberg <[hidden email]> wrote:
>>
>>
>>
>> On 14.04.2011, at 20:56, Eliot Miranda wrote:
>>
>>
>> On Thu, Apr 14, 2011 at 3:23 AM, Bert Freudenberg <[hidden email]> wrote:
>>>
>>>
>>> On 14.04.2011, at 04:46, David T. Lewis wrote:
>>>
>>> >
>>> > On Wed, Apr 13, 2011 at 07:07:57PM -0700, Colin Putney wrote:
>>> >> On Wed, Apr 13, 2011 at 6:58 PM, David T. Lewis <[hidden email]> wrote:
>>> >>
>>> >>> Understood, though my question was intended to be about the existing
>>> >>> primitiveMillisecondClock, which will presumably be retained for a
>>> >>> few more years. Andreas committed a fix for a rather nasty bug related
>>> >>> to a constant in the image being out of sync with a constant in the VM.
>>> >>> The method comment noted that "This should be primitive but it ain't"
>>> >>> so I was just offering to add the primitive and update Squeak trunk
>>> >>> to use it when available.
>>> >>
>>> >> Why does the existing primitiveMillisecondClock have to be maintained?
>>> >> Is there a lot of code that depends on it rolling over? No sarcasm
>>> >> intended, it's an honest question.
>>> >
>>> > It is used by Time class>>millisecondClockValue, so see senders of
>>> > #millisecondClockValue.
>>> >
>>> >> From the point of view of the VM, the primitive needs to be maintained
>>> > because many existing images expect it to be there. From the point of
>>> > view of the image, a different and better implementation can easily
>>> > be adopted. My question was from the point of view of the VM, if we
>>> > assume that many images will expect primitiveMillisecondClock to be
>>> > there, should we also add primitiveMillisecondClockMask such that
>>> > those images can obtain the correct mask value if they choose to
>>> > do so (both the VM and the image changes are minor updates).
>>> >
>>> > With respect to code that depends on the clock rollover, I expect
>>> > that the most serious concern would related to socket timeouts, which
>>> > might intermittently affect server applications, Seaside, etc.
>>> >
>>> > To be clear, the patch that Andreas committed will fully address
>>> > the problem for all current VMs and images, so this discussion
>>> > has little or no practical impact. It's really just about tidying
>>> > up some loose ends just in case the the primitiveMillisecondClock
>>> > ends up getting used for a few years longer than any of us might
>>> > care to anticipate ;)
>>> >
>>> > Dave
>>>
>>> I agree that it should have been made a primitive long ago. However, adding it now would only make sense if we anticipate that it will ever change. And since Eliot is advocating to switch over to a 64 bit clock anyway, what's the point of changing the old one now?
>>>
>>> I'd still retain the old primitive for accessing millisecondClockValue because it certainly can be cheaper (no LargeInts). Or was there a proposal to actually change the old primitive, instead of adding the high-res one?
>>
>> I've heard this argument advanced (that the old interface is cheaper because of no large integers) but I think it's largely a straw man.  If you consider the simplicities that accrue from using a 64-bit clock that can't wrap and is synchronised to wall time (i.e. that Time now is derived from those same microseconds) then it's reasonable to assume the large int allocation cost will be substantially if not entirely recouped by simplicities higher up in Time, Delay et al.  No, I don't have figures; only experience with VW where we didn't notice any degradation but did loose a number of painful 45 1/2 day bugs.
>> 2¢
>> Eliot
>>
>> I don't disagree, in particular with running on Cog which is much more comparable to VW than the interpreter. But what speaks against retaining the old primitive even if it is unused in modern images?
>
> Nothing.  I just ant to get us onto a good time basis, and I need to stop blathering and do something :)
>
>>
>> So do you propose to add the primitiveMillisecondClockMask primitive in anticipation of changing primitiveMillisecondClock to answer an absolute time?
>
> I wouldn't do that.  In Cog (and these can be added to Interpreter) there are separate primitives that answer UTC and local microseconds since 1901.  The old wrapping milliseconds is still available from the old primitive but implemented by truncating the 64-bit microseconds (IIRC after subtracting the start time)
>
>>
>> In light of what Igor reported I'd think that having the time be monotonically increasing is quite valuable, too. Or do we need to have in-image logic to catch the clock jumping backwards?
>
> We had a discussion a few months ago about the right way to handle this in the VM, i.e that the VM assumes that jumps of the order of a few minutes are clock adjustments, not drift. I need to implement this and test against adjusting the clock backwards.  How Delay copes with clock adjustments is another issue, both for durations and absolute deadlines.  What's a reasonable trade-off between implementation feasibility, desired semantics and sanity?  Right now Delay provides only durations (seems fine to me) but under the covers this gets turned into a deadline.  What happens to a duration (and under the covers to a deadline) when the clock is adjusted?


AFAIK Squeak VM primitive are using a millisecond ticker clock, which
are not affected by wall clock adjustment (a system increasing this
counter monotonically and its not related to system time).
If Cog VM 'millisecond' clock primitive are linked with system time,
then by adjusting time , say back by 5 minutes, all scheduled Delays
will receive 'bonus' of +5 more minutes more before being signaled.
Which is of course unacceptable.

But apart from this Delays still have to deal with clock wrap
around/adjustments, for cases, when delays are saved with image.
Then at that point there are initialization, which rescheduling delays
based on remaining time left.


>>
>> - Bert -
>>
>>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.