RFR: 8278518: String(byte[], int, int, Charset) constructor and String.translateEscapes() miss bounds check elimination

[Vladimir Kozlov]

On Tue, 11 Jan 2022 16:06:27 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> In the micro benchmark for this bug, the bytecode has a single loop
> head with 2 backedges. One branch is taken a lot more frequently than
> the other (for instance, profiling reports 3820938 for the most
> common, 134068 for the least common). When ciTypeFlow builds its loop
> tree, the least common loop ends up as the inner loop (ciTypeFlow uses
> the tail block number to order loops with a shared header). Then
> ciTypeFlow clones the inner loop head.
> 
> The results I get then is:
> 
> StringBenchmark.safeDecoding    avgt    5  141.965 ± 53.511  ns/op
> StringBenchmark.unsafeDecoding  avgt    5  123.051 ± 77.855  ns/op
> 
> The unsafe version uses unsafe instead of standard array accesses. The
> reason for the unsafe version is to demonstrate that a missed range
> check elimination in the common path hurts performance (the range
> check is not performed on the loop iv but another phi so can't be
> eliminated).
> 
> The patch I propose takes back branch count (from profile data) into
> account when building the ciTypeFlow tree. As a consequence, the inner
> loop (the one for which the loop head is cloned), is the most most
> frequent one. The range check in the common path is also hoisted in
> that case (it's now performed on the iv). Running the micro benchmark
> again, I get:
> 
> StringBenchmark.safeDecoding    avgt    5  53.368 ± 2.232  ns/op
> StringBenchmark.unsafeDecoding  avgt    5  55.565 ± 5.124  ns/op
> 
> Both are improved (2-3x) and the unsafe version doesn't perform better.

Good. Can you add JMH benchmark for this case?

src/hotspot/share/ci/ciTypeFlow.cpp line 2541:

> 2539:         return leaf; // Already in list
> 2540:       if (current->head()->pre_order() < lp_pre_order)
> 2541:         break;

Can you add `{}` for these checks too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7034