RFR: 8358592: Assert in Assembler::ptest due to missing SSE42 support [v5]

[Guanqiang Han]

On Mon, 14 Jul 2025 18:18:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Guanqiang Han has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Update full name
>>  - Merge remote-tracking branch 'upstream/master' into 8358592
>>  - update regression test
>>  - Update Test8358592.java
>>    
>>    run on x86_64
>>  - add regression test for JDK-8358592
>>  - Merge remote-tracking branch 'upstream/master' into 8358592
>>  - 8358592: Assert in Assembler::ptest due to missing SSE42 support
>>    
>>    Setting "-XX:UseSSE=1" in command line prevents the code from entering the block which causes UseSSE42Intrinsics to not be correctly set.
>
> Okay, forget about other flags. My proposal regarding SSE4_2 for re-writing was because we should not have such sets under specific CPU's families.  SSE4_2 features bit set regardless that: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L2930
> 
> We also check `supports_sse4_2` outside CPUs specific codes for `UseCRC32CIntrinsics` for example.
> Originally only Intel supported, that is why it was placed there. And then code was copied for AMD. We don't need to do it separately.
> 
> An other reason to put such code under specific CPU if on other cpus it is slow/broken. sse4_2 is very old, I think we should not worry about that.

hi @vnkozlov , Thank you for the clarification and background — that makes sense.

I’ve also reviewed the code, and I agree that supports_sse4_2 can be moved outside of the CPU-specific sections. However, I’d suggest applying this change only for the UseCRC32CIntrinsics flag at this time. Some of the other flags depend not only on supports_sse4_2, but also on additional conditions or CPU-specific characteristics. To avoid unintended side effects and to keep the change minimal and well-scoped, I think it’s safer to limit the refactoring to this one flag for now.

Let me know if that sounds good to you — I can update the patch accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/26151#issuecomment-3072183557