[Vm-dev] Measuring allocations

Eliot Miranda eliot.miranda at gmail.com
Thu Jun 1 14:52:08 UTC 2017

Hi Jan,

> On 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. 

Plus the block arg to timesRepeat:.  And the size of an Array in 32-bits is

    (slots >= 255 ifTrue: [16] ifFalse: [8])
    + (slots = 0 ifTrue: [8] ifFalse: [slots + 1 * 2 // 2 * 8])

i.e. 32-bit objects are rounded up to a 64-bit boundary. Spur objects have at least one slot. Slot sizes greater than 254 require an overflow header (255 marks an overflow header).

Hence in 64-bits
    (slots >= 255 ifTrue: [16] ifFalse: [8])
    + (slots = 0 ifTrue: [8] ifFalse: [slots * 8])

There's a primitive in Behavior that answers the byte size of an instance so you don't have to know the formula.  The primitive is used in one of the failingBasicNew: methods to compute how much to grow memory by when a huge allocation fails.

> Note that: 
> * Ideally, I'd like to exclude allocations made by other threads 

Then run at high priority.

>   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? 

What exactly do you want to measure?  There is no allocation count, as that would slow down allocation.  Time taken to allocate  would be derived by sending timeTiRun to the above and subtracting the time for a null loop to run, and the time taken in GC.

The time taken in GC is maintained by the vm.  See vmParameterAt: and surrounding.  If you open the About Squeak dialog in a Squeak image this is nicely displayed in the VM Stats tab (IIRC).

> Thanks, Jan


More information about the Vm-dev mailing list