(AT|AFTER) (NEW|NEWARRAY|NEWMULTIARRAY) triggered only once

I am using the (AT|AFTER) (NEW|NEWARRAY|NEWMULTIARRAY) spec for a module that performs an audit of the number of allocations for specific classes. This functionality is working well, except my numbers were not adding up. After some investigation, I found a behavior that may be a bug, or confusion on my part regarding the spec.

Consider a scenario to track NEW for 2 types: BigInt, and int[]. I instrument the following method:

static BigInt newBigInt() {
  final BigInt b;
  if (shouldInflate) {
    final int[] val = new int[random.nextInt(1024) + 1];
    b = new BigInt(val);
  }
  else {
    b = new BigInt(0);
  }

  return b;
}

Note, that int[] and BigInt are instantiated in the block for shouldInflate=true, and only BigInt is instantiated in the block for shouldInflate=false.

I create the following rules:

RULE BigIntTest.newBigInt BigInt
CLASS foo.bar.BigIntTest
METHOD newBigInt
AFTER NEW BigInt
IF true
DO foo.bar.AuditReport.onNew($CLASS, $NEWCLASS)
ENDRULE

RULE BigIntTest.newBigInt int[]
CLASS foo.bar.BigIntTest
METHOD newBigInt
AFTER NEW int []
IF true
DO foo.bar.AuditReport.onNew($CLASS, $NEWCLASS)
ENDRULE

I placed breakpoints inside the 2 blocks in the newBigInt method (for shouldInflate=true and false), and looked at the numbers that were being reported to AuditReport.onNew(). I observed that in the case of shouldInflate=true, only the trigger for NEW int[] was happening, and the trigger for NEW BigInt was not. For shouldInflate=false, however, the NEW BigInt** trigger was happening.

In the documentation section on AT/AFTER NEW, there is a spec for mitigating this kind of scenario with multiple injection points. Specifically, it is this the part "* [count | ALL ]" in:

AFTER NEW [ type ] [ [] ] * [count | ALL ]

Looking at the TestAtNew.btm file, I can't see an example usage of this syntax. Except, there are some lines with an integer following the class name, such as here.

I've tried different variations of numbers and 'ALL', but all of my trials led to error if there is anything after the class name (or "[]").

So, in summary, the bug is regarding the '[ count | ALL ]' spec.

This issue is related to BYTEMAN-281, and the [ count | ALL ] spec is described a bit more here.

Thanks for your time, and the instrumentation-ability of NEW|NEWARRAY|NEWMULTIARRAY. Byteman is the only instrumentation agent that supports this (at least that I know of).