RFR(M): 8181211: C2: Use profiling data to optimize on/off heap unsafe accesses
paul.sandoz at oracle.com
Tue May 30 19:19:23 UTC 2017
Thanks for looking at this.
A further clean up of the ByteBuffer code is to unify heap and direct implementations to consistently use the double addressing mode, where for the latter a null from a field is read and passed for the heap object. We conservatively held off doing that due to performance concerns. Do you think your patch will help here too?
> On 30 May 2017, at 07:07, Roland Westrelin <rwestrel at redhat.com> wrote:
> 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the hotspot-compiler-dev