[foreign-memaccess] RFR 8237082: Workaround C2 limitations when working with long loops
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Tue Jan 14 17:45:31 UTC 2020
Addressed all comments:
http://cr.openjdk.java.net/~mcimadamore/panama/8237082_v3
I've also added a new benchmark (LoopOverNew), as well as fixed the JNI
code which went out of sync after the package renaming.
Maurizio
On 14/01/2020 15:06, Maurizio Cimadamore wrote:
> Hi,
> both C2 and Graal do not like for loops with long computations inside
> - in C2, the bound-check-elimination code (BCE) is extremely sensitive
> to which opcodes are used when putting together offsets in a linear
> expression [1]. So, whenever C2 sees a long opcode being used (e.g.
> LMUL, or LADD) the BCE logic bails out, which means that in such cases
> we get no bounds check hoisting.
>
> The medium/long term solution is, obviously, to fix C2 [2], so that it
> works on long loops as well as with int loops - after all, this is
> where many of the new APIs we are designing are headed.
>
> As a short term boost, I've put together a patch which classifies
> segments as either small or large; if a segment is small, then we can
> use some trickery to force int opcodes to be used in offset
> computations instead of their long counterparts. Doing so removes most
> of the performance bottlenecks associated with indexed var handle
> access, some of which were visible in the synthetic benchmarks (see
> LoopOverNonConstant [3]).
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8237082_v2/
>
> Cheers
> Maurizio
>
> [1] -
> http://hg.openjdk.java.net/panama/dev/file/b94889c7e153/src/hotspot/share/opto/loopnode.cpp
> [2] - https://bugs.openjdk.java.net/browse/JDK-8223051
> [3] -
> http://hg.openjdk.java.net/panama/dev/file/fb3c9c52fdff/test/micro/org/openjdk/bench/jdk/incubator/foreign/LoopOverNonConstant.java
>
>
More information about the panama-dev
mailing list