RFR: 8263891: Changes for 8076985 missed the fix.

Roland Westrelin roland at openjdk.java.net
Mon Mar 22 08:21:44 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

Looks good to me.

-------------

Marked as reviewed by roland (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3102


More information about the hotspot-compiler-dev mailing list