[Vm-dev] microsecond timing for GC work

[David T. Lewis]

On Tue, Jan 19, 2010 at 10:54:35AM -0800, John M McIntosh wrote:
>  
> Ok, we maybe Ian can comment since the the code for the millisecond clock has been start at zero. 
> 
> Also if we return a value starting at epoch then we'll always end up with a large integer object which is costly and on base squeak systems could trigger a GC event, right
> now we just end up with a small integer at least for a few day(s)... 
> 
> Perhaps we could look at having  two primitives one to return the microsecond clock from image startup, the other to return it from epoch start? 
> 

Yes I agree, two separate primitives would be better for this.

> Also the ioSecond primitive has been based on localTime versus  time() as per the Unix VM code below. 
> 

And this is a Very Bad Thing if you want to support time zones with
daylight savings transitions.

Lex Spoon suggested 10 years ago that we should have a primitive
that answers UTC time plus time zone offset in a single call. He
was right, and I guess somebody (tm) should do something about that
one of these days.

The Smalltalk epoch is ambiguous in Squeak, so it would be better to
use the more clearly defined Posix epoch. Conversion to Squeak epoch
is trivial as long once you decide what time zone the Squeak epoch
occurred in.

Would anyone object to the addition of a primitive that answers
Posix seconds (to some reasonable precision) plus time zone offset?
This would be a named primitive in addition to John's microsecond
primitive.

Dave