trace-summary: record message bytes per entry method per interval (reviewed line, twin of #3937)

[lvkale]

Reviewed-line twin of #3937 (same commit, cherry-picked onto reviewed-with-reconverse; #3937 stays for classic main and was approved there by ritvikrao and ericjbohm). Original description follows, then the reconverse test.

A summary detail trace says how much time each entry method spent in an interval and how many times it ran there — which is how many messages it processed — but not how much data those messages carried. Projections can therefore show message counts over time for a summary trace but nothing about volume, while a .log trace gives both.

The size is already handed to the tracer and thrown away. TraceSummary::beginExecute(int event, int msgType, int ep, int srcPe, int mlen, ...) takes a length it never reads, and the envelope form drops it before calling that one:

void TraceSummary::beginExecute(envelope *e, void *obj) {
  ...
  else beginExecute(-1,-1,e->getEpIdx(),-1);   // e->getTotalsize() discarded

What this does

• passes the envelope's total size through, and remembers it for the matching endExecute the way execEp is remembered;
• accumulates it into a msgBytes array beside numExecutions, in the same bin the run is counted in, with the same allocation, shrink() and teardown;
• writes a MsgBytesPerEPperInterval line into the .sumd file in the same run length encoding as the two arrays already there.

Only messages delivered to an entry method contribute. Packing and unpacking, which numExecutions also counts because updateSummaryDetail is called for them from endPack/endUnpack, add no bytes.

The quantity recorded is envelope::getTotalsize(), which is exactly what trace-projections records as a message length, so byte figures from a summary trace and from a .log trace mean the same thing.

Cost and compatibility

One 8 byte counter per bin per entry method while tracing, beside the 8 byte time and 4 byte count already kept, and one more line per processor in the .sumd file. Nothing changes when +sumDetail is off.

Readers that predate the new line are unaffected: Projections' SumDetailReader ignores labels it does not recognise, by explicit design ("this allows new formats to be implemented without immediately rendering this tool useless"), so an older Projections reads a newer .sumd unchanged. No file version bump is therefore needed. The Projections side that displays the new data is charmplusplus/projections#166.

Testing

Built netlrts-darwin-arm8 with -DTRACING=1 on macOS (Apple clang 16) and ran a program that sends 100 messages to each of two entry methods, the second carrying twice the payload of the first. Envelope overhead is the same for both, so the difference between their recorded byte totals must be exactly 100 x payload:

small: 100 messages, expected 100   OK
large: 100 messages, expected 100   OK
bytes(large) - bytes(small) = 102400, expected 102400 (= 100 messages x 1024 extra bytes)   OK
implied envelope overhead: 112.0 bytes per message

(The payload has to be a multiple of the message alignment for that identity to hold — with a 1000 byte payload the two messages round to different padding and the difference is 800 short, which is alignment rather than accounting.)

Projections then read the same trace back and reported 113,600 bytes over 100 messages for one entry method and 216,000 over 100 for the other, matching the file. An existing 1920 processor trace written before this change still loads, with sizes reading zero throughout.

Tested on reconverse (2026-09-30)

Built reconverse-darwin-arm8 with --enable-tracing --with-production, linked a program with -tracemode summary that sends 100 messages to each of two marshalled entry methods, the second carrying 1024 bytes more, and ran it with +pe 1 +sumDetail. The .sumd file gained the line

MsgBytesPerEPperInterval 0+3298 113600 0+21 216000 0+485

113,600 and 216,000 bytes for the two entry methods: a difference of 102,400 = 100 x 1024, and the same totals the classic test produced (112 bytes of envelope per message on both runtimes). Note that on reconverse the trace modules exist only in a build made with --enable-tracing; a plain production build reports "No such tracemode summary".

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

🤖 Generated with Claude Code