Adding an array multiple times leads to the fast update via `IncRC`.
This hides the allocation that is there on the first addition. In this
commit add another benchmark which measures Add/Remove together, to
ensure that `switch` in `refCounter.Add` is entered. Benchmark results
are meaningful, because `Add`/`Remove` have almost identical implementation.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
And determine the need for Null dynamically. For some reason the only dynamic
context is Contract.Call. CALLT is not dynamic and neither is a call from
native contract, go figure...
We use it a lot in (*Blockchain).IsTxStillRelevant().
name old time/op new time/op delta
IsSignatureContract-8 19.1ns ± 5% 1.2ns ± 4% -93.81% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
IsSignatureContract-8 0.00B 0.00B ~ (all equal)
name old allocs/op new allocs/op delta
IsSignatureContract-8 0.00 0.00 ~ (all equal)
Perform add/set/remove operations with VM type firstly, and with
refcounter after that. It is needed to be able to extend add/set/remove
operations with extra checks.
We can omit DAO wrapping for safe methods and for those methods that are not
wrapped into try-catch block. However, we still need to persist
notificationsCount changes for these methods to the parent context.
Reference implementation:
e167f03e25/src/neo-vm/ExecutionContext.cs (L77).
Turns out that exception-related code (try\finally handling) is the only
place where next instruction pointer bounds are not pre-checked before
assignment. This statement is true for both go and C# implementations.
However, C# code has duplicate check located inside the
InstructionPointer setter for all instructions except the
exception-related ones. Neo-go code doesn't perform this duplicate check.
Thus, C# VM FAULTs execution in case of invalid TRY/FINALLY offsets, and
neo-go VM does not.
This commit reverts a part of
https://github.com/nspcc-dev/neo-go/pull/2396. This bug is discovered
thanks to test added in https://github.com/neo-project/neo-vm/pull/453.
Which allows to create verification scripts without keys.PublicKey which is
convenient in some cases where we already have serialized key and don't want
to waste time decompressing it.
Currently the only known reason this can happen is processing
ENDFINALLY opcode before the corresponding ENDTRY.
Signed-off-by: Evgeniy Stratonikov <evgeniy@nspcc.ru>
