RFR(M): 8181211: C2: Use profiling data to optimize on/off heap unsafe accesses
Vladimir Kozlov
vladimir.kozlov at oracle.com
Fri Jun 2 17:54:51 UTC 2017
Looks reasonable. I submitted internal testing of combination
8176506+8181211.
Vladimir
On 5/30/17 7:07 AM, Roland Westrelin wrote:
>
> http://cr.openjdk.java.net/~roland/8181211/webrev.00/
>
> The not yet pushed 8176506 makes code emitted for unsafe accesses a lot
> more conservative and harder for c2 to optimize when an access is not
> known to be on or off heap. This change proposes that profile data be
> used to detect on or off heap accesses allowing c2 to better optimize
> sequences of unsafe accesses (at the cost of an extra null
> check/assert).
>
> With this change:
>
> 1- argument profiling is enabled at unsafe put* and get* call site
>
> 2- I found that enabling argument profiling but not return value
> profiling is broken. That change fixes it.
>
> 3- C2 needs to be able to tell, from profile data, whether a pointer is
> always null, never null or sometimes null. So far, whether a pointer
> is always null wasn't made available to c2.
>
> 4- the C2 unsafe code now checks profile data when it cannot tell
> whether an access is on or off heap and emits a guard.
>
> 5- load from non null objects at an offset guaranteed to fall in the
> object are not pinned anymore.
>
> With this change, Paul's benchmarks perform as well with 8176506+8181211
> as they do without (actually better because of 5). Andrew's byte buffer
> tests generate a main loop with 8176506+8181211 that's identical to what
> is generated currently.
>
> Roland.
>
More information about the hotspot-compiler-dev
mailing list