[Vm-dev] Measuring allocations

Jan Vrany jan.vrany at fit.cvut.cz
Mon Jun 12 12:21:49 UTC 2017


Hi Eliot,

On Wed, 2017-06-07 at 18:17 -0700, Eliot Miranda wrote:
>  
> Hi Jan,
> 
> On Thu, Jun 1, 2017 at 1:17 AM, Jan Vrany <jan.vrany at fit.cvut.cz>
> wrote:
> > Hi folks,
> > 
> > Having a Spur VM, I wonder how to measure heap allocations made 
> > by a process executing a particular block, from within the image. 
> > For example, let's have following block:
> > 
> > [
> >    | a |
> > 
> >    100 timesRepeat: [
> >       a := Array new: 100
> >    ]
> > ].
> > 
> > When run, this block allocates - if I'm correct - some 100 *
> > (<object
> > header size> + 4*100) bytes.
> > 
> > Note that:
> >  * Ideally, I'd like to exclude allocations made by other threads
> >    but having allocations made by all threads would be OK too.
> >  * Block can span multiple scavenges even oldspace collects.
> >  * As shown in the example above, I need to take garbage into 
> >    an account.
> > 
> > How to best measure this?
> 
> I just committed the code for Spur, so as soon as the CI has built
> VMs you should be able to do
> 
> 	initialAllocation := Smalltalk vmParameterAt: 34.
> 	self doMyThing.
> 	bytesAllocated := (Smalltalk vmParameterAt: 34)
> - initialAllocation
> 
> and/or
> 
> 	Smalltalk vmParameterAt: 34 put: 0.
> 	self doMyThing.
> 	bytesAllocated := Smalltalk vmParameterAt: 34

Nice, thanks! I just tried and it seems to work fine - it does return
plausible numbers for some quick and trivial tests. 

> 
> It needs testing.  Note that it measures bytes allocated at the
> lowest level I can manage so it should include everything, including
> hidden allocations in the GC's marked stack and remembered tables,
> and the class tables.  I *think* the code is not confused by heap
> growth and shrinkage.  I'd love for anyone interested to review the
> code (see the VMMaker.oscog-eem.2237 commit).

I'm sorry I don't feel experienced enough / familiar with VM internals
to review the code. The general idea is OK - or at least it worked 
well enough for me in the past. But the devil is in the detail, as
always. 

Anyways, thanks! 

Jan




> > Thanks, Jan
> > 
> 
> _,,,^..^,,,_
> best, Eliot


More information about the Vm-dev mailing list