Byte code snap-shot to save runtime heap

[seanshpark]

IoT.js scripts are growing as development goes on and at the same time, it uses more Jerry heap space.
As of today, IoT.js built-in scripts consume about 64KB memory still more to go. If there is a way to save the heap memory it can give more to IoT.js application.
The idea is like V8's snap-shot;

1. run Jerry with IoT.js built-in scripts
2. make Jerry drop byte codes and Literals in to binary
3. convert that binary to C source so that they exist in .text area (in ROM for embedded devices)
4. build IoT.js
5. when IoT.js is executed give snap-shot .text area memory to Jerry

Please add comments about how to make this possible and huddles to overcome.

[seanshpark]

This is the second idea talked on CC

[lemmaa]

@seanshpark Thank you for kind explanation. I think we have better to consider ipm distribution as a bytecode format at the same time.

[seanshpark]

@egavrin , do you have any plans for this item? If possible can you please list "what" and "how-to" in brief to start? I hope to participate on this.

[egavrin]

@seanshpark definitely ^_^
We'll start this activity after implementation of updated byte-code storage required for proper eval implementation. And no earlier than end of June, since we have very tight schedule.
Regarding implementation, there are set of possibilities:

1. Pre-parse. Straightforward, but less effective
Take JS file on input and generate C-code for the file, like in current unit-tests ./tests/unit/*

opcode_t opcodes[] =
  {
    getop_meta (OPCODE_META_TYPE_SCOPE_CODE_FLAGS, // [ ]
                OPCODE_SCOPE_CODE_FLAGS_NOT_REF_ARGUMENTS_IDENTIFIER
                | OPCODE_SCOPE_CODE_FLAGS_NOT_REF_EVAL_IDENTIFIER,
                INVALID_VALUE),
    getop_reg_var_decl (128, 129),  // var tmp128 .. tmp129;
    getop_var_decl (0),             // var a;
    getop_assignment (129, 1, 1),   // tmp129 = 1: SMALLINT;
    getop_assignment (0, 6, 129),   // a = tmp129 : TYPEOF (tmp129);
    getop_exitval (0)               // exit 0;
  };

In this implementation we keep the existing interpretation logic as is, while eliminating parser and byte-code overheads. This will positively affect both the performance and memory consumption.

2. AOT. A bit more effective, but will require modification of interpreter
There is no need to keep table of opcodes and no overhead from interpretation loop will appear.
Input JS file can be translated into set of C-calls of opfunc_* handlers, which can be inlined and additionally optimized by the compiler.

   opfunc_meta (OPCODE_META_TYPE_SCOPE_CODE_FLAGS, // [ ]
                OPCODE_SCOPE_CODE_FLAGS_NOT_REF_ARGUMENTS_IDENTIFIER
                | OPCODE_SCOPE_CODE_FLAGS_NOT_REF_EVAL_IDENTIFIER,
                INVALID_VALUE),
   opfunc_var_decl (0),             // var a;
   opfunc_assignment (129, 1, 1),   // tmp129 = 1: SMALLINT;
   opfunc_assignment (0, 6, 129),   // a = tmp129 : TYPEOF (tmp129);
   opfunc_exitval (0)               // exit 0;

[seanshpark]

@egavrin , thank you for describing in detail. it's not like what I was thinking - much like how V8 is doing, but your way seems very nice and adaptive.