Integrated: 8263891: Changes for 8076985 missed the fix.
Vladimir Kozlov
kvn at openjdk.java.net
Mon Mar 22 16:19:41 UTC 2021
On Sat, 20 Mar 2021 17:02:23 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
> The fix for JDK-8076985 was supposed to be this:
> https://cr.openjdk.java.net/~kvn/8076985/webrev.00/src/hotspot/cpu/x86/x86_64.ad.udiff.html
>
> But the final push had only comment change:
> https://hg.openjdk.java.net/jdk/jdk/rev/4d1c4400c75d
>
> Here is explanation of the fix from 8076985 RFR:
>
> First, this is about how C2 generates code for *constant* class pointers.
>
> A little history here. When we implemented compressed oops and class pointers we had PermGen and classes were Java objects. We used the same decoding/encoding code for oops and classes - we used the same register containing Heap Base address. It was profitable to decode constant class and reuse it [1]. Also we greatly benefited on SPARC since decoding 32-bit constant required 4 instructions instead of up to 7 instructions to load 64-bit constant.
>
> Now compressed class decoding is different and always takes 2 instructions on x86 [2] if either base or shift is not 0.
>
> As result we generated 3 instructions to get full class pointer from compressed 32-bit constant (example for base = 0, shift = 3):
>
> movl $0x200001d5,%r11d
> movabs $0x0,%r10
> lea (%r10,%r11,8),%r10
>
> Also when we store compressed class pointer into new object header we don't use register anymore on x86 - keeping it in register does not help now:
>
> movl $0x200001d5,0x8(%rax)
>
> Aleksey suggested to have only one instruction to load full 64-bit class pointer:
>
> movq $0x100000EA8,%r10
>
> It frees one register and uses 10 bytes instead of up to 20 bytes of code on x86.
>
> In JDK 9 SAP contributed nice change [3] to have choice when to use 'compressed class pointer + decoding' or full '64-bit constant class pointer'. It significantly simplified changes for this RFE.
>
>
> I ran performance testing but did not see difference - we don't use biased locking now and as result we don't need to load prototype header from class. But there are other places where we need load from class.
>
> Tested tier1-3
This pull request has now been integrated.
Changeset: f08bf4b9
Author: Vladimir Kozlov <kvn at openjdk.org>
URL: https://git.openjdk.java.net/jdk/commit/f08bf4b9
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
8263891: Changes for 8076985 missed the fix.
Reviewed-by: roland
-------------
PR: https://git.openjdk.java.net/jdk/pull/3102
More information about the hotspot-compiler-dev
mailing list