[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?
> 
> confused,
> Eliot

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:

  Name: VMMaker-dtl.164
  Author: dtl
  Time: 28 March 2010, 1:44:25 pm
  UUID: 8637033b-c991-462f-9970-318688bbc998
  Ancestors: VMMaker-eem.163
  
  VMMaker 4.0.1
  Reference Mantis 7458: [Vm-dev] microsecond timing for GC work
  
  Add primitiveMicrosecondClock and microsecond GC instrumentation by John McIntosh.
  Add primitiveUtcWithOffset.
  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
  CCodeGenerator>>writeDefaultMacrosOn:.
  
  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.

Dave



More information about the Vm-dev mailing list