[Vm-dev] Measuring allocations
leves at caesar.elte.hu
Fri Jun 2 10:59:25 UTC 2017
You should be able do that in your image by replacing #basicNew,
#basicNew: and #shallowCopy with method wrappers which would sum up the
size of the allocated objects in ProcessLocalVariables before returning
the new objects.
On Thu, 1 Jun 2017, Jan Vrany wrote:
> On Thu, 2017-06-01 at 07:52 -0700, Eliot Miranda wrote:
>> 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
> Sure, sure. The exact number is not important for me right now.
>> > Note that:
>> > * Ideally, I'd like to exclude allocations made by other threads
>> Then run at high priority.
> Good point, thanks. I always forget about that.
>> > 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?
> I want to know how much given code allocates. For example that
> given piece of code in total allocated 2.5GB. Say.
>> There is no allocation count, as that would slow down allocation.
> Fair enough.
>> 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).
> It is indeed. But in this case I'm not interested in time spent in GC
> Thanks, Jan
More information about the Vm-dev