Introduce integer ecma-value representation to reduce the double allocations

[zherczeg]

The patch is an initial patch to store 28 bit integer values in ecma_values. This is a first patch in a series of patches which exploits these integer numbers to accelerate math performance, since most numbers are small integer numbers in JavaScript. The memory saving is resulted by not allocating doubles for these integer numbers. The follow-up patches will likely not affect memory.

RPi2 results

                      Benchmark |          RSS(+ is better) |                   Perf(+ is better)
                     3d-cube.js |   84k ->   68k : +19.048% |   2.176s ->   2.096s :  +3.676%  (+-0.720%) : [+]
         access-binary-trees.js |   72k ->   72k :  +0.000% |   1.200s ->   1.144s :  +4.667%  (+-0.940%) : [+]
             access-fannkuch.js |   32k ->   32k :  +0.000% |   6.366s ->   6.084s :  +4.430%  (+-0.515%) : [+]
                access-nbody.js |   36k ->   36k :  +0.000% |   2.414s ->   2.452s :  -1.574%  (+-1.491%) : [-]
    bitops-3bit-bits-in-byte.js |   24k ->   24k :  +0.000% |   1.378s ->   1.336s :  +3.048%  (+-1.462%) : [+]
         bitops-bits-in-byte.js |   24k ->   24k :  +0.000% |   2.058s ->   1.894s :  +7.969%  (+-0.685%) : [+]
          bitops-bitwise-and.js |   24k ->   24k :  +0.000% |   2.798s ->   2.882s :  -3.002%  (+-1.157%) : [-]
          bitops-nsieve-bits.js |  164k ->  164k :  +0.000% |   3.956s ->   4.042s :  -2.174%  (+-0.743%) : [-]
       controlflow-recursive.js |  124k ->  112k :  +9.677% |   0.808s ->   0.740s :  +8.416%  (+-1.044%) : [+]
                  crypto-aes.js |  104k ->   96k :  +7.692% |   2.898s ->   2.690s :  +7.177%  (+-0.583%) : [+]
                  crypto-md5.js |  168k ->  168k :  +0.000% |   1.194s ->   1.202s :  -0.670%  (+-1.224%) : [≈]
                 crypto-sha1.js |  116k ->  116k :  +0.000% |   1.130s ->   1.144s :  -1.239%  (+-0.998%) : [-]
           date-format-tofte.js |   56k ->   56k :  +0.000% |   1.730s ->   1.648s :  +4.740%  (+-0.962%) : [+]
           date-format-xparb.js |   52k ->   52k :  +0.000% |   0.742s ->   0.690s :  +7.008%  (+-1.154%) : [+]
                 math-cordic.js |   28k ->   24k : +14.286% |   2.456s ->   2.486s :  -1.221%  (+-1.071%) : [-]
           math-partial-sums.js |   24k ->   24k :  +0.000% |   1.346s ->   1.410s :  -4.755%  (+-0.878%) : [-]
          math-spectral-norm.js |   32k ->   32k :  +0.000% |   1.190s ->   1.188s :  +0.168%  (+-0.774%) : [≈]
               string-base64.js |  156k ->  148k :  +5.128% |   5.290s ->   5.178s :  +2.117%  (+-1.191%) : [+]
                string-fasta.js |   40k ->   40k :  +0.000% |   2.702s ->   2.688s :  +0.518%  (+-1.502%) : [≈]
                Geometric mean: |     RSS reduction: 3.108% |                   Speed up: 2.146% (+-0.244%) : [+]

Binaries
master: 173,568
branch: 173,480

[zherczeg]

The binary size is decreased because a lot of ecma_alloc_number () calls are eliminated.

[LaszloLango]

Missing comment:
https://travis-ci.org/Samsung/jerryscript/jobs/128006828
./jerry-core/ecma/base/ecma-helpers-value.c:376: error: missing comment at the end of function: /* ecma_is_number_equals_to_positive_zero */

[zherczeg]

Thank you, fixed.

[LaszloLango]

LGTM

[akosthekiss]

Terminology: to me, simpler is better. I'd suggest using ECMA_TYPE_DIRECT and perhaps even ECMA_TYPE_FLOAT. Even the comment of "non-ptr" starts explaining the type as "DIRECTly encoded"; and we haven't used "VALUE" suffices at the other labels (OBJECT, STRING) either. And its better to name something what it is than what it isn't.

We could argue that terminology is unimportant enough not to worry about -- but using the right terms helps understanding IMHO.

[zherczeg]

Ok. I used this name first, but I didn't particularly like it. But I am not against it either.

[zherczeg]

Patch updated

[akosthekiss]

To remove the need for code duplication, the above if could/should be written as

  if (((ecma_number_t) integer_value == ecma_num)
      && (((integer_value == 0) && ecma_is_number_equals_to_positive_zero (ecma_num))
          || (ECMA_INTEGER_NUMBER_MIN <= integer_value && integer_value <= ECMA_INTEGER_NUMBER_MAX)))
  {
    // do something (only once)
  }

(The above is still within line length limits.)

[zherczeg]

The above is incorrect, because the ECMA_INTEGER_NUMBER_MIN <= integer_value && integer_value <= ECMA_INTEGER_NUMBER_MAX part includes the integer_value == 0

That is, it is the same as:

if (((ecma_number_t) integer_value == ecma_num)
    && (ECMA_INTEGER_NUMBER_MIN <= integer_value && integer_value <= ECMA_INTEGER_NUMBER_MAX)))

probably a ?: is better

[zherczeg]

Changes are added as a separate commit, but I plan to squash it. Please review.

[akosthekiss]

This should rather end with | ECMA_DIRECT_TYPE_INTEGER_VALUE

[zherczeg]

Since only NaNs are created now, I made a ecma_make_nan_value function. If we ever need other constants we could continue this discussion.

[akosthekiss]

LGTM