Observatory: allocation profile: separate accumulators for old-space allocation and promotion

[rakudrama]

I want to answer the question: how many bytes did my program allocate?

The old-space accumulators count allocations directly into old-space AND promotions from new-space.
This double-counts some objects.
This means that you can't add the numbers to arrive at the total number of allocations.
Promotions should be counted separately.
If promotions were counted separately, the UI could provide an alternate simplified view which unifies (adds) old-space and new-space counts. The UI could display the unified counts and only add-on the old- and new- counts by request.

It would be nice for all columns to have totals too. Assuming mostly new-space allocation, the total for new-space bytes would approximate the answer to my question.

[iposva-google]

We might not want to pay for the extra memory needed to account for promotion vs direct old-space allocation. Would you prefer to know the amount of objects promoted or the objects directly allocated in old space since accumulator clear?

In general you can assume that overall every allocation originated in new space. Except for allocations larger than the new space allocation cutoff (which varies but is generally greater than 16KB). The only Dart user code objects which can potentially be large enough to trigger this condition are variable sized objects such as strings, arrays (in Dart known as fixed size Lists), typed data. The VM allocates some of its internal structures directly in old space, because we know that they will survive for a very long time.

The "in general" refers to the following condition: Compile time constants are directly allocated in old-space, but compared to the overall amount of object allocations they are a drop in the bucket and once your program reaches steady state there are no constants being allocated.

[rakudrama]

"Would you prefer to know the amount of objects promoted or the objects directly allocated in old space since accumulator clear?"

If forced to choose: I prefer direct allocations.

What I really want to know is properties of the program independent of exact GC behaviour. I might learn something interesting from comparing total old-space occupancy vs (allocations + promotion) but it is unlikely I can change the program's behaviour reliably without complete control over GC, and that is usually a bad idea.

FWIW I'm not sure I accept that the extra memory is expensive for the applications I am profiling - it is a new instance count and bytes count per class-id (< 10K counters vs several GB of allocation). But that maybe applies only to my kind of application.