core/vm: jit vm

[obscuren]

• Stage 1: (this PR) This will be the base for the improvements that will soon begin on the VM. This PR optimised the VM slightly by compiling byte code to instructions (function calls) and removes the need for random access in the byte-code. When the regular VM kicks in it checks if a compiled version of the contract (identified by H(code)) is available and if so will use the compiled version instead. If no compiled version is available it will compile the byte code in a separate thread and continues using the byte-code VM.
• Stage 2: during byte-code VM operations periodically check if the compilation of the compiled contract has finished and if so move the execution over.
• Stage 3: implement segmentation core/vm: code segmenting #1324

Status

stage 1 implemented
stage 2 implemented, but commented out
stage 3 TODO (future PTR)

[obscuren]

oops :)

[fjl]

Why is this being changed?

[obscuren]

Because the GOROOT should determine the go version. Not PATH. Got a better suggestion?

[fjl]

                                                                                  GOROOT is not always present in the environment.Using it here would require that people set it before building.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          ‎

[fjl]

I am guessing that you added this in order to be able to build/test with different Go versions.
If that's what you want, we can add a variable GO that allows you to specify the go binary.
You could then invoke make as follows:

make GO=/path/to/go/bin/go1.5
// or even
make GO=go1.5

[fjl]

I don't think it's possible to use a single shared base because it is pushed to the stack.

[fjl]

Sorry, that was a bit misguided. We also push common.BigFalse and friends to the stack in other places.
Bigints on the stack are not mutated. I think what @Gustav-Simonsson meant is that we could do something
like this to avoid allocating base when it is not required.

x, y := S256(stack.pop()), S256(stack.pop())
if y.Cmp(common.Big0) == 0 {
    stack.Push(common.Big0)
    return
}
...

[obscuren]

We can, yes. I don't think it will make much difference but certainly agree that not requiring base in certain areas is cleaner

[obscuren]

Actually the reason why it is as it is right now is because the code has been copied from the origin VM to their respective functions. I wanted minimal changes to the opcodes before "moving on" to reduce the risk of bugs and errors. Again I certainly agree it can and should be refactored.

[fjl]

btw x.Abs(x) mutates the stack value if x < (1<<255).
We might want to look into that. Can this happen?

[fjl]

ahh, no, it shouldn't happen because the stack never contains negative values. S256 always creates a new int if the number is negative, so Abs is fine then. But this is really hard to see.

[Gustav-Simonsson]

btw this is a general potential danger with the current impl, if somewhere somehow one can push a negative int to the stack, it can be exploited by a number of other op codes.

[obscuren]

We need better big int objects (proper unsigned ints really). It shouldn't happen unless someone screws it up now

[fjl]

I think one way to make this safer would be to move S256 to a method on stack, e.g. popS256 and document under which conditions the value refers to the live int on the stack.

[obscuren]

Hmm, interesting thought. Maybe we should remove push and add pushU256 and a pushS256. Remove all manual S/U256 before the push operation.

[Gustav-Simonsson]

Hmm, we could potentially avoid this hashing by reusing the contract address as id, but then it's not unique on code. Which could be fine if most contracts use CALLCODE on existing contracts for the heavy lifting. What do you think?

[fjl]

I think the sha3 is fine for now. It's not that slow.

[Gustav-Simonsson]

JIT should be in caps.