RFD: C2: Poor code quality for Unsafe
Paul Sandoz
paul.sandoz at oracle.com
Thu Jul 28 10:10:17 UTC 2016
Hi Andrew,
Sorry, i went back and re-read your email, i got mixed up with direct and heap buffers.
I observe similar behaviour as you do on x86 for direct int buffer views.
For a direct int buffer view the compiled floss method has poorly generated code. However, when that floss method gets inlined into the on-stack-replaced main i observe good generated code. Seems fragile.
I also verified my patch does not regress for heap int buffer views, and that patch uses a similar express for calculating the Unsafe address as for direct buffer views.
Perhaps the code generation issue is also associated with single addressing mode? We recently switched the single addressing accessors to use the double address accessors passing null as the base value.
It would be good to talk with Roland about this, as he implemented some improvements to the addressing calculations for Unsafe access for arrays and heap buffers.
Paul.
> On 27 Jul 2016, at 16:55, Andrew Haley <aph at redhat.com> wrote:
>
> On 27/07/16 15:08, Paul Sandoz wrote:
>> Ah, ok, i did not realize you had that patch applied as well, i was thrown off base because you mentioned the following method:
>>
>> protected int ix(int i) {
>> return (i << $LG_BYTES_PER_VALUE$) + offset;
>> }
>>
>> which is not used for access [*] in the patch(s).
>
> It *is* used in Direct-X-Buffer, which is what gets inlined. The
> inlining looks like this:
>
> @ 18 ByteBufferTest::floss (24 bytes) inline (hot)
> @ 4 java.nio.Buffer::capacity (5 bytes) accessor
> @ 13 java.nio.DirectIntBufferU::put (18 bytes) inline (hot)
> @ 6 java.nio.Buffer::checkIndex (22 bytes) inline (hot)
> @ 9 java.nio.DirectIntBufferU::ix (10 bytes) inline (hot)
> @ 13 jdk.internal.misc.Unsafe::putInt (8 bytes) force inline by annotation
> @ 4 jdk.internal.misc.Unsafe::putInt (0 bytes) (intrinsic)
> @ 4 java.nio.Buffer::capacity (5 bytes) accessor
>
> I can confirm that your corrected patch makes no difference to any of
> this.
>
> Andrew.
>
More information about the hotspot-dev
mailing list