Regexp refactoring and optimizations

[LaszloLango]

• Move RegExp bytecode to new files
• Fix style and comments
• Implement a RegExp cache
• Reduce RegExp bytecode size

[zherczeg]

Regexp flags does not affect byte code? e.g. /a/ and /a/i are the same? Even if it is true noew, it might affect future optimizations.

[LaszloLango]

This is not good. This won't work correctly. The flags should be checked as well here. The first 2 bytes are different on your example. I'll fix it.

[zherczeg]

What I don't understand is how a regex disappears from the cache if GC deletes it? And why the cache size is 10? I would prefer a compile time default with a default of 8.

[LaszloLango]

@zherczeg, I just figured out a small number. There is no an exact reason why ten. 8 is is good.
The answer for the first question:

    if ((cached_bytecode_p->flags >> ECMA_BYTECODE_REF_SHIFT) > 0)
    { ...  }
    else
    {
      /* mark as free, so it can be overridden if the cache is full */
      free_idx = *idx;
    }

If there is such an element in the cache then it is marked as free and a new compiled bytecode could be inserted there. We can improve this algorithm, because this is a basic implementation. I wanted to make the search and maintain of the cache as simple (and fast) as possible. The cache saves memory in rare situations only, so I think we don't need too complicate algorithm for this, because it can cause big perf regression.

[LaszloLango]

@zherczeg, I've updated the PR, please check.

[zherczeg]

No need a newline above.

[zherczeg]

Do you see improvement with caching? I am still thinking about an "eviction" mechanism, but it could go in a follow-up patch (or move the regex caching into a follow-up patch).

[LaszloLango]

The cache only helps in rare situations. I think it is not so common to use the same regex in a file. There are some examples in test262.

• ch15/15.10/15.10.2/15.10.2.12/S15.10.2.12_A1_T1 failed in non-strict mode
• ch15/15.10/15.10.2/15.10.2.12/S15.10.2.12_A2_T1 failed in non-strict mode
• ch15/15.10/15.10.2/15.10.2.12/S15.10.2.12_A3_T1 failed in non-strict mode
• ch15/15.10/15.10.2/15.10.2.12/S15.10.2.12_A4_T1 failed in non-strict mode
• ch15/15.10/15.10.2/15.10.2.12/S15.10.2.12_A5_T1 failed in non-strict mode
• ch15/15.10/15.10.2/15.10.2.12/S15.10.2.12_A6_T1 failed in non-strict mode

Currently we are failing on these tests with out of memory error. The cache helps a bit, but does not solve the whole problem. For example in ch15/15.10/15.10.2/15.10.2.12/S15.10.2.12_A1_T1 there are 64 checks. Without the cache it bails out on the 47th check, but with the cache it only bails out on the 53th.

What do you mean with "eviction" mechanism? Like a FIFO algorithm, when the cache is full? In this case I'm still thinking that only slows down the engine, but won't has enough gain to worth it.

[zherczeg]

Yes, I think a FIFO eviction mechanism could be good. But I think this is enough for one patch.
So LGTM. But please improve the caching in a follow-up patch.