We don't use all of the Stack functionality for it, so drop useless methods
and avoid some interface conversions. It increases single-node TPS by about
0.9%, so nothing really important there, but not a bad change either. Maybe it
can be reworked again with generics though.
v.estack is used throughout the code to work with estack, while ctx.sc.estack
is (theoretically) just a reference to it that is saved on script load and
restored to v.estack on context unload. The problem is that v.estack can grow
as we use it and can be reallocated away from its original slice (saved in the
ctx.sc.estack), so either ctx.sc.estack should be a pointer or we need to
ensure that it's correct when loading a new script. The second approach is a
bit safer for now and it fixes#2798.
Share parameters parsing code between 'contract invokefunction' and
'vm run' commands. It allows VM CLI to parse more complicated parameter
types including arrays and file-backed bytestrings.
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.
