[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