Detect compilation while benchmarking

[JaroslavTulach]

Pull Request Description

Enables engine.TruffleCompilation in std-benchmarks, collects the logs and dumps compilation into to System.err when a benchmark is influenced by dynamic compilation.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Java,
• Run benchmarks with compilation detection on: benchmark run

[JaroslavTulach]

Nice "side-effect" of this change is: We can see the errors from the compiler like this one:

PermanentBailoutException: Too deep inlining, probably caused by recursive inlining.
Inlined methods ordered by inlining frequency:
org.enso.interpreter.runtime.data.Type.allTypes(EnsoContext)

I guess we should finally fix this allTypes problem!

[JaroslavTulach]

There seems to be 26 compilation detected messages. Those benchmarks might benefit from increasing the warmup time.

Update: there seems to be (at least) hundred "compilation detected" messages in the new run (with 0862a0f).

[JaroslavTulach]

0862a0f fixes the problem with too deep inlining in Type.allTypes. Running the benchmarks again to verify the current state.

[JaroslavTulach]

Update: there seems to be (at least) hundred "compilation detected" messages in the new run (with 0862a0f).

The benchmarks finish without errors, but some results are really skewed:

as can be seen the second iteration is marked as Iteration 2: <failure>... but that's not the cause of such a dramatic slowdown - that's missing @ExplodeLoop - added in a5f84ff

[radeusgd]

Great to be able to see the compilation problems in the benchmarks :)

[JaroslavTulach]

We have a usage of blacklisted string concatenation method. Hidden behind @TruffleBoundary in fe6d2be

[JaroslavTulach]

Final benchmark run scheduled. It just dumps info, it doesn't throw AssertionError. As such the run should be green, but the log can be used to find out whether a particular benchmark was influenced by compilation or not. That's probably good enough to start with for now.

[Akirathan]

I like the fact that the Truffle engine compilation is logged into System.err and no Exception is thrown from within the @Teardown benchmark method, as that might cause some issue with result reporting. I hope this will enable us to set better parameters for the benchmarks.

[JaroslavTulach]

The benchmarks finish without errors, but some results are really skewed:
... but that's not the cause of such a dramatic slowdown - that's missing @ExplodeLoop - added in a5f84ff

Collections_fold_list is really fixed. Other stdlib benchmarks also look good.