Incorrect MaxVectorSize Reported by JVM on AMD targets under SDE

[Jatin_Bhateja]

Hi SDE Team,

I am using latest SDE version 9.58 and experiencing a strange problem on AMD targets.

When I try to query target supported MaxVectorSize through Java virtual machine on an x86 AVX512 AMD Ryzen 7 system it reports incorrect value as 16 bytes, without SDE I see correct value i.e. 64 bytes. 

PROMPT>sde64 --version

Intel(R) Software Development Emulator. Version: 9.58.0 external (0)

Copyright (C) 2008-2025, Intel Corporation. All rights reserved.

PROMPT>java --version

openjdk 25-ea 2025-09-16

OpenJDK Runtime Environment (build 25-ea+27-3363)

OpenJDK 64-Bit Server VM (build 25-ea+27-3363, mixed mode, sharing)

PROMPT>java -XX:+PrintFlagsFinal --version | grep MaxVectorSize

intx MaxVectorSize = 64 {C2 product} {default}

PROMPT>sde64 -dmr -- java -XX:+PrintFlagsFinal --version | grep MaxVectorSize

intx MaxVectorSize = 16 {C2 product} {default}

I spent some time to debug the issue, it could be in the OS state save / restoration, but I also see some strange non-determinisim around VPBROADCASTD instruction. Original value in lower 32 bits of XMM0 is not broadcasted to all the lanes of ZMM0 register, please refer screenshot of issue in the attachment.

Let me know if you need more information from my end.

Best Regards,

Jatin 

[AdyT_Intel]

Hello,

I have no access to AMD machine and I was unable to reproduce this on my Intel platforms with the JVM version I have.

It might be CPUID bits in the DMR CPUID configuration that are not set correctly. But it is hard to tell which ones. Our emulation for CPUID instruction is approximate and it does not provide full accurate representation of the simulated CPU.

Does it happen with any emulated CPU or only with DMR?

Ady.

[Jatin_Bhateja]

Hi Ady,

There are multiple issues here, one is related to the incorrect MaxVectorSize reported by the JVM, and another one is associated with a crash seen on JVM startup with SDE 9.58.

While I understand that MaxVectorSize computation is solely dependent on CPU feature checks and the ability to perform successful ZMM register save restoration across signal handling during JVM initialization, there seems to be some problem in save/restoration of ZMM across signal handling with SDE, especially on AMD targets with DMR, GNR, and older Xeons emulation. 

TURIN>lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 52 bits physical, 57 bits virtual
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Vendor ID: AuthenticAMD
Model name: AMD EPYC 9B45
CPU family: 26
Model: 2
Thread(s) per core: 2
Core(s) per socket: 1

TURIN>sde64 -dmr -- java -XX:+PrintFlagsFinal --version | grep MaxVectorSize
     intx MaxVectorSize = 16 {C2 product} {default}
TURIN>java -XX:+PrintFlagsFinal --version | grep MaxVectorSize
     intx MaxVectorSize = 64 {C2 product} {default}

Given that AVX10 support for converged vector ISA will also be supported by AMD, SDE emulation support at MaxVectorSize is important here.

I have logged an issue in Java Bug System (JBS) for this https://bugs.openjdk.org/browse/JDK-8367314

Will add more information here after further debugging.

Best Regards,

Jatin Bhateja

[Jatin_Bhateja]

Please use latest JDK-26 for verification https://download.java.net/java/early_access/jdk26/14/GPL/openjdk-26-ea+14_linux-x64_bin.tar.gz

[Jatin_Bhateja]

It seems "serialize" instruction supported since Sapphire Rapids see as illegal instruciton in AMD Turin DMR emulation.

TURIN>cat test.c

int main() {
asm volatile ("serialize" : : : );
return 1;
}

TURIN>sudo gcc test.c -o app
TURIN>sde64 -dmr -- ./app
Illegal instruction at address = 579fc27b1131: 0f 01 e8 b8 01 00 00 00 5d c3 00 f3 0f 1e fa
Image name: /home/sandboxes/app
Offset in image: 0x1131
If you believe your application should attempt to execute
this illegal instruction (and others that may be present),
Then use this knob: -emit-illegal-insts 0
and this error message will be avoided.
Use -print-exception-details to get more details.

SDE ERROR: Illegal instruction at address = 579fc27b1131: 0f 01 e8 b8 01 00 00 00 5d c3 00 f3 0f 1e fa
Image name: /home/sandboxes/app
Offset in image: 0x1131
If you believe your application should attempt to execute
this illegal instruction (and others that may be present),
Then use this knob: -emit-illegal-insts 0
and this error message will be avoided.
Use -print-exception-details to get more details.

exception info: thread index = 0,context change reason = 0,exception code = 0x4
Backtrace:
==========
main+0x000000008 at /home/sandboxes/app+0x000001131
__libc_init_first+0x000000088 at /lib/x86_64-linux-gnu/libc.so.6+0x00002a578
__libc_start_main+0x00000008b at /lib/x86_64-linux-gnu/libc.so.6+0x00002a63b
_start+0x000000025 at /home/sandboxes/app+0x000001065

Error opening the file sde-error.txt