[CLOSED] Instrumentation of heap usage (dynamic)

[aionbot]

Issue created by yulongaion (on Wednesday May 09, 2018 at 14:30 GMT)

Specifically for object and array allocation.

Some idea:

• Object allocation can be measured by the pre-calculated object size
• Array size can be computed at runtime based the input oprand.

[aionbot]

Comment by jeff-aion (on Thursday May 10, 2018 at 16:15 GMT)

There are effectively 3 different angles to this:

1. Direct allocations of JDK types we explicitly white-list for the contract's use: these will be assigned a fixed, per-type cost
2. Direct allocations of types defined within the contract, itself: we will assign a fixed cost to these, based on load-time investigation of these class instance shapes
3. Direct allocations of array types: these sizes can only be known at runtime so we either need to account for them, right before allocation, or find a way to allocate them within a static helper (since this should only be a small set)

(3) would be simple and ideal but requires some investigation to determine if it is actually an option. Failing that, we will need to add extra annotation calls prior to each array allocation bytecode.
Note that object allocation incurred through our runtime methods is not attributed to the contract, but does represent a fixed and documented cost, per-call.

[aionbot]

Comment by jeff-aion (on Thursday May 10, 2018 at 19:14 GMT)

Initial investigation of whether or not (3) is possible:

• anewarray - This seems possible. Replacing the anewarray with ldc ; invokestatic would give us the required semantics. The static helper is really just Array.newInstance(clazz, length) but note that the class argument must be the last parameter to the function, or we need to add a swap to get the stack into the right shape.
• multianewarray - This one is tricky since the number of primitive slots on the stack depends on an argument to this bytecode, meaning it could be anywhere in [2..255]. There is no general way of building such a variable argument method (or call), in Java. This probably means we will need to put a limit on this (or generate a long list of tedious helpers). Beyond that, it works exactly the same was as anewarray (including the point that we probably want the class argument last, not first, to avoid the need to re-arrange the stack).
• newarray - This one is the simplest, if we want to handle each primitive as a special case (which is feasible, there are only a few) since the calling convention for the newarray bytecode.

Next step is to prototype these helpers and the bytecode manipulation.

NOTE: I will assume that this bytecode manipulation should be done after we have already built a fee schedule, since this is our own permutation, not the contract, itself.

[aionbot]

Comment by jeff-aion (on Friday May 11, 2018 at 19:39 GMT)

Redefined this issue to deal specifically with the dynamic cases of allocation tracking: arrays. #22 has been cracked to handle the largely disjoint set of problems related to static allocation tracking.