DynamicMetrics Tool Completeness

[smarr]

PR #348 is extending the DynamicMetrics tool to measure actor-specific issues.

While doing this work, I noticed the DyM does not correctly report the call targets anymore.
This broke between the 0.6.0 and 0.7.0 releases.

PR #348 rectifies some of this, but for the moment, I'll likely not get to everything, so here a list if issues that should addressed for completeness:

• make sure we record everything, even for the megamorphic cases, so, we need to check
  • generic dispatch operations
  • use of indirect call nodes
  • all uses of direct call nodes
  • block primitives (Re-add support recording closure application targets and other DyM fixes #351 does some of this, but not all, for instance the BlockDispatchNode)
  • handle transitions from specific instrumentation (ValuePrim) to more generic (MessageSend) see below (specific to generic)

Actor statistics that could be added:

• promise chain length
• messages sent per turn
• number of turns per actor
• messages received, messages sent per actor

Specific To Generic

One known limitation is the recording of targets for ValuePrims when we have a mixed use of blocks and objects. For instance Array>>#putAll: becomes a generic message send, for which we still have the counter, but don't have the detailed information anymore. Perhaps, I need a way to invalidate the counter, and transition invocation counts etc to another counter for message sends.

Known Issues

• recording of receiver information seems unreliable (see details below)
• information gets lost when transition to megamorphic and generic case (at least for message sends)

Recording of Receiver Details

Currently we seem to have problems with this. The PingPong benchmark has many examples.

1 Platform.ns:19:3:416                    true          1         0           1                    true           1          0            1            0
2  Savina.ns:100:18:10                    true     119997         0           1                    true      159996          0            1        39999
3   Savina.ns:106:31:4                    true     119997         0           1                    true      159996          0            1        39999
4   Savina.ns:107:31:4                    true          3         0           1                    true           4          0            1            1
5  Savina.ns:117:20:10                    true     120000         0           1                    true      160000          0            1        40000
6  Savina.ns:129:54:26                    true          3         0           1                    true           4          0            1            1
7  Savina.ns:130:54:24                    true          3         0           1                    true           4          0            1            1
8   Savina.ns:131:16:5                    true          3         0           1                    true           4          0            1            1
9   Savina.ns:95:18:10                    true          3         0           1                    true           4          0            1            1

Losing Information

One known limitation for this are situations where we have a mixed use of blocks and objects, for instance Array>>#putAll: becomes a generic message send, for which we still have the counter, but don't have the detailed information anymore. Perhaps, I need a way to invalidate the counter, and transition invocation counts etc to another counter for message sends.