Optimize compilespeed

[rPraml]

Hello, I've tried to improve the compile speed, especially, if many exception handlers are involved (see CodegenTest.testManyExceptionHandlers)

This test takes in original 33s on my machine.

• step 1: Use binary search for getSuperBlockFromOffset
  As long as I see, the itsSuperBlocksStarts array contains the starts in sorted order, so I use binary search in getSuperblockFromOffset.

This brings a performance boost down to 3.5s

• step 2: narrowed lookup range for big exception tables
  I also narrowed the lookup range for big exception tables and throw away the exception table entries, that are definitively irrelevant. See f0831e0
  Now the test runs in 1.2s

• step 3: Optimized finding locals
  A further optimization in finding the locals brings down the test case to 0.6s

• step 4: TypeInfo.merge do simplest check first
  This is not really measurable, but showed up as "hot" method in the profiler, so I tried to optimize it also

The "all test time" goes down from about 11:50 to 11:20

[gbrail]

This all looks very good to me. I was hoping it'd speed up test execution for Rhino itself, but sadly it didn't really make a difference. Do you or does anyone else have an example of some complex JavaScript that now compiles a bunch faster so that we can document that for the record?

[rPraml]

@gbrail I've investigated much time in optimizing test execution (compile and run speed) and did only find a few places where optimization is done. (see other PRs) Unfortunately, most of them is not really measurable.
I've only found the CodegenTest.testManyExceptionHandlers test, where this change makes a huge difference:

As far as I see, the amount of exception handlers goes into compile speed with a complexity of ~ O(n^3) and the CodegenTest creates 1000 of them. If you double the number, the test takes ~8 times longer.

There were 3 nested for - loops, one of them could be replaced with the binary search, so that you'll get O(n^2 log(n))

All in all, compile speed will only increase if you have many of exception blocks (which may be an edge case)

BTW: You can increase the testexecution speed by factor ~2 if jacoco is disabled.

[tuchida]

• java.lang.VerifyError in language/statements/try of test262 #915

Rhino is not currently testing the try statement in test262.
I added language/statements/try to test262.properties, and found that the number of errors was the same before and after the modification.

language/statements/try 117/195 (60.0%)

[gbrail]

This seems safe enough to merge as part of 1.7.14. I'll test it one more time and then do it.

[gbrail]

Thank you! I merged this manually because I wanted fewer commits but I wanted to also separate the spotless commits from the real work.