RFR: 8359327: Incorrect AVX3Threshold results into code buffer overflows on APX targets

[Jatin Bhateja]

On Thu, 12 Jun 2025 11:49:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> As per the latest architecture-instruction-set-extensions-programming-reference manual version 57[1] , upcoming Diamond Rapids server with APX feature has a different CPU family ID (19) than prior Xeons (6).
> 
> Recently integrated EEVEX to REX2 demotion support with [JDK-8351994](https://bugs.openjdk.org/browse/JDK-8351994) already handles this through a newly defined _VM_Version::is_intel_server_family()_ API, but the existing AVX3Therehold setting is agnostic to this change, which causes code buffer overflows during arraycopy stubs generation.
> 
> Patch fixes this issue and also appropriately increments final code buffer size to prevent buffer overruns during stub generation with non zero AVX3Thereshold. 
> 
> [1] https://www.intel.com/content/www/us/en/content-details/851355/intel-architecture-instruction-set-extensions-programming-reference.html?wapkw=intel%20architecture%20instruction%20set%20extensions%20programming%20reference

-Xlog:stubs output before and after this patch. Array copy stubs use a 256-bit vector for non-zero AVX3Threshold, which results in a bulkier stub sequence and shows up in the final stub size.

Before Patch:-
[6.165s][info][stubs] StubRoutines (finalstubs)  [0x00007fc74aac46e0, 0x00007fc74aad0f58] used: 31850, free: 19470

After Patch:-
[7.273s][info][stubs] StubRoutines (finalstubs)  [0x00007fbf3308eee0, 0x00007fbf3309bf28] used: 26186, free: 27134

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

PR Comment: https://git.openjdk.org/jdk/pull/25780#issuecomment-2969626248