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

[Eliot Miranda]

On Thu, Apr 14, 2011 at 3:23 AM, Bert Freudenberg <bert at freudenbergs.de>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 <lewis at mail.msen.com>
> 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


> - Bert -
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110414/9a97bc07/attachment.htm