RFR(S): 8155729: C2: Skip transformation of LoadConP for heap-based compressed oops

Doerr, Martin martin.doerr at sap.com
Tue Oct 4 08:53:42 UTC 2016


Hi,

after the bug was approved for 9, I'd like to ask for review of the new webrev:
http://cr.openjdk.java.net/~mdoerr/8155729_LoadConP/webrev.01/

It is modified to affect only PPC64 and AARCH64.

Thanks and best regards,
Martin


-----Original Message-----
From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] 
Sent: Freitag, 29. April 2016 19:05
To: Doerr, Martin <martin.doerr at sap.com>; hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR(S): 8155729: C2: Skip transformation of LoadConP for heap-based compressed oops

Looks good to me. We need corresponding changes in our closed code too.

Thanks,
Vladimir

On 4/29/16 7:06 AM, Doerr, Martin wrote:
> Hi,
>
>
>
> I have opened a new bug for the proposal which was discussed in thread 8154826.
>
> The summary is:
>
>
>
> C2's final graph reshaping performs the following transformation:
>
> Original pattern: LoadConP + Storage access
>
> Transformed pattern: LoadConN + DecodeN heap-based + Storage access
>
>
>
> This seems to be fine for simpler compressed oops mode. It also seems to be fine on x86 which can match the decoding
> into the operand of the Storage access instruction.
>
>
>
> Other platforms should better skip the transformation:
>
> -PPC can load the ConP from constant pool. Decoding takes a lot of instructions, because the heap base needs to get loaded.
>
> -SPARC can use that as well.
>
> -aarch64: LoadConN+DecodeN has a higher latency than LoadConP.
>
>
>
> We can always skip the transformation in heap-based compressed klass mode. Matching DecodeNKlass as operand is currently
> not implemented.
>
>
>
> Webrev is here:
>
> http://cr.openjdk.java.net/~mdoerr/8155729_LoadConP/webrev.00/
>
>
>
> Please review. I will also need a sponsor, please.
>
>
>
> Best regards,
>
> Martin
>
>
>


More information about the hotspot-compiler-dev mailing list