RFR: 8254252: Generic arraycopy stub overwrites callee-save rdi register on 64-bit Windows [v3]
Christian Hagedorn
chagedorn at openjdk.java.net
Wed Oct 14 07:04:12 UTC 2020
On Tue, 13 Oct 2020 16:11:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:
>> Since [JDK-8241825](https://bugs.openjdk.java.net/browse/JDK-8241825), MacroAssembler::load_klass requires a temporary
>> register to decode the klass pointer. In the generic arraycopy stub, rdi is used for that on 64-bit Windows because r9
>> is already used as an argument register: https://hg.openjdk.java.net/jdk/jdk/rev/0bb101fbeb10#l17.32
>> The problem is that rdi is callee-save [1] but not restored when returning from the stub. This leads to register
>> corruption and more or less random crashes in the caller.
>> Although JDK-8241825 is part of JDK 15, this was never a problem because we did not set the _WIN64 macro in adlc and as
>> a result accidentally treated rdi (and rsi) as caller-save:
>> https://github.com/openjdk/jdk/blob/b9873e18330b7e43ca47bc1c0655e7ab20828f7a/src/hotspot/cpu/x86/x86_64.ad#L89
>> Now that this got fixed as part of [JDK-8248238](https://bugs.openjdk.java.net/browse/JDK-8248238) [2], we hit the bug.
>>
>> Unfortunately, we are running out of caller-save registers on Windows. Since rcx, rdx, r8 and r9 are used for
>> arguments, only rax, r10 and r11 remain which are already used as temporary registers and live throughout the stub
>> code. I've decided to free up r11 by postponing the load of the array length which is only needed on Windows anyway
>> (because only Windows passes the 5th argument on stack). Thanks, Tobias
>>
>> [1] https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
>> [2] https://openjdk.github.io/cr/?repo=jdk&pr=212&range=11#sdiff-8
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>
> Fixed indentation
Looks good.
-------------
Marked as reviewed by chagedorn (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/603
More information about the hotspot-compiler-dev
mailing list