New Allocator and improved String handling.

[dbatyai]

This PR is the continuation of the work in #678. It was suggested there to use the recordset implementation to reduce wasted memory. I investigated this approach, but the results were rather dissapointing, as execution became almost two times slower on each test.
So, in order to reduce wasted memory while also gaining the performance benefit of using heap buffers, I experimented with a new allocator that can allocate blocks that are a multiple of 8 bytes.
Here are the results:

                  Benchmark |      RSS<br>(+ is better) |               Perf<br>(+ is better)
                 3d-cube.js |   84k ->   88k :  -4.762% |   2.643s ->   2.657s :  -0.505%  (+-2.810%)
     access-binary-trees.js |   80k ->   80k :  +0.000% |   1.410s ->   1.373s :  +2.601%  (+-2.346%)
         access-fannkuch.js |   36k ->   36k :  +0.000% |   7.973s ->   7.793s :  +2.257%  (+-1.150%)
            access-nbody.js |   40k ->   40k :  +0.000% |   3.080s ->   3.067s :  +0.433%  (+-2.842%)
bitops-3bit-bits-in-byte.js |   32k ->   28k : +12.500% |   1.727s ->   1.687s :  +2.317%  (+-2.678%)
     bitops-bits-in-byte.js |   32k ->   28k : +12.500% |   2.657s ->   2.457s :  +7.528%  (+-2.618%)
      bitops-bitwise-and.js |   28k ->   24k : +14.286% |   3.680s ->   3.467s :  +5.797%  (+-2.695%)
      bitops-nsieve-bits.js |  152k ->  152k :  +0.000% |  30.107s ->  29.920s :  +0.620%  (+-2.970%)
   controlflow-recursive.js |  176k ->  176k :  +0.000% |   0.890s ->   0.897s :  -0.749%  (+-3.717%)
              crypto-aes.js |  120k ->  108k : +10.000% |   4.707s ->   3.680s : +21.813%  (+-1.099%)
              crypto-md5.js |  180k ->  168k :  +6.667% |  21.473s ->   8.527s : +60.292%  (+-0.166%)
             crypto-sha1.js |  124k ->  124k :  +0.000% |   9.733s ->   4.497s : +53.801%  (+-1.646%)
       date-format-tofte.js |   60k ->   64k :  -6.667% |   2.240s ->   2.273s :  -1.488%  (+-1.477%)
       date-format-xparb.js |   60k ->   56k :  +6.667% |   1.083s ->   0.893s : +17.538%  (+-3.958%)
             math-cordic.js |   32k ->   36k : -12.500% |   3.000s ->   2.913s :  +2.889%  (+-1.103%)
       math-partial-sums.js |   32k ->   28k : +12.500% |   1.660s ->   1.643s :  +1.004%  (+-1.993%)
      math-spectral-norm.js |   36k ->   36k :  +0.000% |   1.520s ->   1.460s :  +3.947%  (+-0.166%)
           string-base64.js |  164k ->  156k :  +4.878% | 149.297s ->  31.220s : +79.089%  (+-0.718%)
            string-fasta.js |   44k ->   36k : +18.182% |   4.547s ->   3.570s : +21.481%  (+-3.595%)
            Geometric mean: |     RSS reduction: 4.224% |               Speed up: 19.896%  (+-0.632%)

Memory usage increased slightly in most cases by a few hundred bytes, because of the removal of recordset, and the rework of the literal storage, but the total memory available also increased by around the same amount, because we no longer have to store bitmaps for memory regions, so this basically evens out.
On the other hand, strings that were previously stored in char_collections now use around 15% less memory in buffers, while also providing significant performance improvement.
It's worth noting, that we also require less intermediate buffers for manipulating strings.
When using --mem-stats, peak memory usage may seem to increase by a larger amount, than stated before, this is the result of garbage collection triggering differently with the new allocation scheme and the increased heap size.

It's also worth noting that the new allocator could also support separated heap regions, which I plan to investigate further, since it could be very useful in some cases. Also, the maximum memory size is now less constrained, although we are still limited to 512kB because of compressed pointers.

[zherczeg]

Wow, nice improvement!

[LaszloLango]

@dbatyai, the following regression test fails: ./tests/jerry/array-prototype-sort.js

[dbatyai]

@LaszloLango, Thanks, the issue is fixed.

[LaszloLango]

@dbatyai, could you rebase the patch to the current master?

[dbatyai]

@LaszloLango, done.

[LaszloLango]

'8192'?

[LaszloLango]

@dbatyai, thanks for the update. Apart from several minor style issues the patch look good to me. :)

[dbatyai]

@LaszloLango, I fixed the issues you mentioned.

[LaszloLango]

@dbatyai, great. Thank you! @zherczeg, could you also review this patch?

[LaszloLango]

@dbatyai, could you check the following test262 test fails:

• ch12/12.6/12.6.4/S12.6.4_A4.1 in non-strict mode
• ch12/12.6/12.6.4/S12.6.4_A4 in non-strict mode
• ch15/15.5/15.5.5/S15.5.5.1_A2 in non-strict mode

UPDATE: S15.1.3.1_A2.5_T1 and S15.1.3.2_A2.5_T1 are passed with bigger timeout. The list is updated.

[dbatyai]

@LaszloLango, I checked the failures. It appears they were caused by an over-indexed array in ecma_op_object_get_property_names which was unnoticed until now. I fixed it and updated the patch.

[LaszloLango]

@dbatyai, thanks for the fix. I did a double-check on your patch and the test262 tests run fine in debug Jerry, so If @zherczeg has no objection then we can land this patch soon.

[zherczeg]

What is the purpose of this macro?

[dbatyai]

It defines a maximum value for the heap limit. Heap limit is, as the name suggest, a limit of memory usage, and whenever the size of allocated memory since the previous limit would hit the next one, we would run garbage collection. The limit was previously set to HEAP_AREA_SIZE / 32 == 8192. Because I increased the size of the heap, garbage collection became less frequent, so I added a maximum value. This way it wouldn't affect environments where the heap size is different.

[zherczeg]

Very nice patch

[zherczeg]

LGTM after the ref count is restored to its old value.

[dbatyai]

Patch is updated.