question about JDK-8172231: SPARC CPU features detection

[Lindenmaier, Goetz]

Hi David, 

do you mind sharing the patch?
As the change was made in OracleJDK, we can 
not reach the changeset from JBS.

Thanks!
  Goetz

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of David Buck
> Sent: Tuesday, April 20, 2021 4:26 AM
> To: Ilarion Nakonechnyy <ilarion at azul.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: question about JDK-8172231: SPARC CPU features detection
> 
> Hi Ilarion!
> 
> The OpenJDK community may want to consider a fix similar to what we did in
> Oracle JDK 11 [0].
> 
> Cheers,
> -Buck
> 
> [0] https://bugs.openjdk.java.net/browse/JDK-8263407
> 
> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Ilarion Nakonechnyy
> Sent: Tuesday, April 20, 2021 4:21 AM
> To: jdk-updates-dev at openjdk.java.net
> Subject: FW: question about JDK-8172231: SPARC CPU features detection
> 
> Dear sirs, good day.
> My name is Ilarion, I’m new contributor for OpenJDK project.
> 
> I have some questions about implementation of fix for bug JDK-8172231:
> SPARC CPU features detection, probably somebody may shed some lights on
> it.
> 
> I’m doing my exercises on JDK 11 and noticed that on exact SPARC CPU block
> zeroing detection feature determines wrong.
> Having system with SPARC64-X CPU, java fails with segmentation violation
> error, on the very beginning of the java run.
> My investigations lead me to MacroAssembler::bis_zeroing() routine.  Where
> begin and end of memory area is cleared by stx instruction, and the rest – via
> stxa(G0, to, G0, Assembler::ASI_ST_BLKINIT_PRIMARY), that supposed to
> zeroing memory, but it doesn’t.
> Turning off block zeroing feature via flag -XX:-UseBlockZeroing helps to avoid
> the crash.
> 
> 
> 
> 
> Decision if CPU has the CPU_blk_zeroing_msk feature based on determining
> another cpu flag,  ISA_ima_msk
> 
> +    // Niagara Core S3 supports fast RDPC and block zeroing.
> 
> +    if (has_ima()) {
> 
> +      synthetic |= (CPU_fast_rdpc_msk | CPU_blk_zeroing_msk);
> 
> +    }
> 
> But there is also mentioned special flag, that corresponds to Block
> initialization feature: ISA_blk_init_msk. That actually isn’t checked at all.
> ( Other than in reporting ) I looked in JDK 8, and  figured out, that block
> zeroing capacity there was decided not  only by ISA flags, but with referring
> on CPU model also:
> 
> -  // On T4 and newer Sparc BIS to the beginning of cache line always zeros it.
> 
> -  static bool has_block_zeroing()       { return has_blk_init() && is_T4(); }
> 
> 
> JDK 8 works well for my case, because BIS instruction isn’t used Despite ISA
> flags that is returned by getisax reports that block initialization is supported
> ( AV_SPARC_ASI_BLK_INIT 0x0080 )
> 
> [0.172s][info][os,cpu  ] getisax(2) returned 1 words:
> 
> [0.172s][info][os,cpu  ]     word 0: 0xc001b1f0
> 
> So, as I can see, the CPU version ( “cpu brand”  in jdk 8 ) has main role in
> detecting CPU block zeroing feature.
> Do you have some more information, probably any doc, where noted why
> CPU version plays such a role in feature detecting for JVM? In CPU
> specifications I didn’t found any clues about this.
> Thank you in advance.