[Vm-dev] getVMParameters broken
David T. Lewis
lewis at mail.msen.com
Sat Aug 14 18:36:36 UTC 2010
On Sun, Aug 08, 2010 at 02:22:25PM -0700, Eliot Miranda wrote:
> On Fri, Aug 6, 2010 at 5:55 AM, Henrik Johansen <
> henrik.s.johansen at veloxit.no> wrote:
> > On Aug 6, 2010, at 2:39 53PM, Adrian Lienhard wrote:
> > >
> > > Hi,
> > >
> > > In recent VMs (Mac and Unix), SmalltalkImage current
> > vmStatisticsReportString is broken, in that it returns nonsense data for GC
> > times:
> > >
> > > ...
> > > GCs 1,145,798 (84ms between GCs)
> > > full 3914 totalling 723,736,998ms (755.3%
> > uptime), avg 184909.8ms
> > > incr 1141884 totalling 248,056,609ms (258.9% uptime),
> > avg 217.2ms
> > > tenures 14,222 (avg 80 GCs/tenure)
> > > Since last view 72 (49ms between GCs)
> > > uptime 3.5s
> > > full 0 totalling 0ms (0.0% uptime)
> > > incr 72 totalling 15,110ms (426.1% uptime), avg 209.9ms
> > > tenures 0
> > >
> > >
> > > primitiveVMParameter in the most recent version of VMMaker package was
> > changed. Does the image-side code need to be adapted or is this a bug in the
> > primitive?
> > >
> > > Thanks,
> > > Adrian
> > It's been changed to a microsecond clock value in recent VM's on Unix/Mac.
> Is this really the case? If so, I think it is completely unnecessary. In
> the Cog VM I also use microseconds to sum GC times but when they are
> answered through getVMParameters they are converted to milliseconds
> (dividing by 1000 is not hard to do). So why change the external interface
> of the primitive when so much existing code depends on it?
Background is at http://bugs.squeak.org/view.php?id=7458.
The VMMaker changes are hidden in the version history due to some merging
(there are two VMMaker-xxx.165.mcz entries, which caused the VMMaker-dtl.164
version to be hidden in the version history), but were introduced here:
Time: 28 March 2010, 1:44:25 pm
Reference Mantis 7458: [Vm-dev] microsecond timing for GC work
Add primitiveMicrosecondClock and microsecond GC instrumentation by John McIntosh.
Fix signature of Interpreter>>dumpImage: (pointer declared as int).
The new primitives require support in the platform code. Default implementations
are provided to allow compilation without these platforms updates, see
Without platform updates, the GC instrumentation falls back to millisecond
precision, the primitiveMicrosecondClock primitive answers (incorrectly) a
millisecond value, and primitiveUtcWithOffset fails the primitive.
The key points are:
- Implementation of #primitiveVMParameter implimentation was changed.
- There is no change to #primitiveMillisecondClock.
- The new #primitiveMicrosecondClock and #primitiveUtcWithOffset are available
for future use, but are currently unreferenced.
As far as I know, the changes to #primitiveVMParameter had no effect
on any code in the image (although I am not certain, perhaps John can
confirm). There was, however a problem in one version of the Windows
VM that led to the discussion. This was a mistake, caused by my misguided
attempt to provide backward compatibility, leading to Andreas being
unaware of required platform changes. The issue should be resolved
now, so hopefully there is no problem ongoing.
More information about the Vm-dev