Windows AArch64 port introduced in JDK 16 does not pass the following JCK tests:

vm/instr/aload_w/aload_w001/aload_w00102m1/aload_w00102m1.html
vm/instr/aload_w/aload_w001/aload_w00102m1t/aload_w00102m1t.html
vm/instr/astore_w/astore_w004/astore_w00401m1/astore_w00401m1.html
vm/instr/astore_w/astore_w004/astore_w00401m1t/astore_w00401m1t.html
vm/instr/dload_w/dload_w001/dload_w00101m1/dload_w00101m1.html
vm/instr/dload_w/dload_w001/dload_w00101m1t/dload_w00101m1t.html
vm/instr/dstore_w/dstore_w005/dstore_w00501m1/dstore_w00501m1.html
vm/instr/dstore_w/dstore_w005/dstore_w00501m1t/dstore_w00501m1t.html
vm/instr/fload_w/fload_w003/fload_w00302m1/fload_w00302m1.html
vm/instr/fload_w/fload_w003/fload_w00302m1t/fload_w00302m1t.html
vm/instr/fstore_w/fstore_w005/fstore_w00502m1/fstore_w00502m1.html
vm/instr/fstore_w/fstore_w005/fstore_w00502m1t/fstore_w00502m1t.html
vm/instr/iload_w/iload_w003/iload_w00310m1/iload_w00310m1.html
vm/instr/iload_w/iload_w003/iload_w00310m1t/iload_w00310m1t.html
vm/instr/istore_w/istore_w005/istore_w00510m1/istore_w00510m1.html
vm/instr/lload_w/lload_w003/lload_w00310m1/lload_w00310m1.html
vm/instr/lstore_w/lstore_w005/lstore_w00510m1/lstore_w00510m1.html
vm/instr/ret_w/ret_w002/ret_w00210m1/ret_w00210m1.html
vm/instr/wide/wide002/wide00201m1/wide00201m1.html
vm/instr/wide/wide002/wide00201m1t/wide00201m1t.html

In case the interpreter calls a method with a large enough number of locals on windows-aarch64, a crash is hit. The root cause is that it allocates space for them on the stack, clears this memory and touches the corresponding memory pages. On linux-aarch64 and macosx-aarch64, the handler in the operating system does not look at the order of page initialization, but in windows-aarch64 it does. The stack grows from high to low addresses and zeroing occurs in the opposite direction - from the lowest to the highest.

More details here: https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack

The suggested fix is to reverse the direction of zeroing.