Safe lazy-pages implementation

[grishasobol]

As it is discussed in #3917 - current gear-lazy-pages impl is not safe, because we handle them inside signal handler. The possible solution is to implement lazy pages using load/store wrapping. To explain the solution let's dived it to several steps.

Raw solution

Append system syscalls, which is uploaded page data from storage

(import "env" "gr_pre_process_memory" (param i32 i32)) ;; first param is addr, second is size

On code instrumentation we will change all load/store operations to corresponding wrapper function:

;; wrapper for `i32.load`, param 1 is base addr, param 2 is offset
(func $i32load (param i32 i32) (result i32) (local i32 $addr) 
    (i32.add (local.get 0) (local.get 1)) ;; calculates addr
    (call gr_pre_process_memory (local.tee $addr) (i32.const 4))
    (i32.load (local.get $addr))
) 
;; similar wrapper functions for all other types of load/store operations 

So, as you can see we call imported function for each load/store operation, which cause significant perf decrease. In my measurements the cost of i32.load operation become x60 times bigger. The cost of one FungibleToken transfer becomes x2 times bigger

gear/examples/fungible-token/tests/benchmarks.rs

Line 208 in a1f9f64

async fn stress_transfer() -> Result<()> {

To solve this perf decrease we can append some optimisations in next steps.

Stack optimisation

Taking solution above we just add check that accessed memory interval lies inside stack memory

;; wrapper for `i32.load`, param 1 is base addr, param 2 is offset
(func $i32load (param i32 i32) (result i32) (local i32 $addr) 
    (local.set $addr (i32.add (local.get 0) (local.get 1))) ;; calculates addr
    (i32.add (local.get $addr) (i32.const 4)) ;; calculates end addr
    i32.const 0x100000 ;; stack end size is known const
    (if (i32.gt) ;; if out of stack memory then run pre preocess syscall
          (call gr_pre_process_memory (local.get $addr) (i32.const 4))     
    )
    (i32.load (local.get $addr))
) 
;; similar wrapper functions for all other types of load/store operations 

Because in common programs the most often are stack memory operations, this optimisation can significantly increase performance in comparison with raw solution.

Cash optimisation

Also some already pre processed pages can be stored on some cash on globals. Most programs does not access many pages during execution, so this cache can be not big. For example 16 pages. Having 16 system i32 globals, we can store there already accessed pages and check this global during execution in order to skip syscall calling to already processed pages. The solution with cache is much more difficult and bigger, so I skip more precise implementation here.