Currently, the whole CPU detection for SPARC CPUs seems to be biased towards Sun/Oracle SPARC CPUs. This leads to some problems when running on new Fujitsu Sparc64-X CPUs.

The first problem is that the helper function is_niagara(int) assumes that machine hardare name (i.e. 'uname -m' or 'sysinfo(SI_MACHINE)') can be used to determine the CPU family. However, this is not true any more since the Fujitsu Sparc64-X CPU implements the same hardware class (i.e. sparc4v) like the CPUs which belong to the Sun/Oracle "UltraSparc T family". We therefore change is_niagara(int) to only return true if we are not running on a Sparc64 CPU.

The second problem is the consistency check which warns if the option UseMemSetInBOT is activated while running with the G1 or CuncurrentMarkAndSweep GC on a new "T family" CPU. This check was initially done in Arguments::check_vm_args_consistency. But that's too early, because later on the GC may be changed to UseConcMarkSweepGC in Arguments::set_ergonomics_flags in which case the VM wouldn't issue any warning. Following the output of a various Java invocations which should all print the warning because the VM is running with UseConcMarkSweepGC and UseMemSetInBOT, but only the first one really does so:

$ java -XX:+UseConcMarkSweepGC -XX:+UnlockExperimentalVMOptions -XX:+UseMemSetInBOT -version
Java HotSpot(TM) Server VM warning: Experimental flag -XX:+UseMemSetInBOT is known to cause instability on sun4v; please understand that you are using at your own risk!
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) Server VM (build 24.45-b08, mixed mode)

$ java -XX:+UseAutoGCSelectPolicy -XX:MaxGCPauseMillis=1000 -XX:+UnlockExperimentalVMOptions -XX:+UseMemSetInBOT -version
java version "1.7.0_45"
Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
Java HotSpot(TM) Server VM (build 24.45-b08, mixed mode)

$java -XX:+UseAutoGCSelectPolicy -XX:MaxGCPauseMillis=1000 -XX:+UnlockExperimentalVMOptions -XX:+UseMemSetInBOT -XX:+PrintFlagsFinal -version 2>&1 | egrep "UseConcMarkSweep|UseMemSetInBOT"
     bool UseConcMarkSweepGC                       := true            {product}           
     bool UseMemSetInBOT                           := true            {experimental}      

Even worse, after the change "8008407: remove SPARC V8 support" has removed the call to VM_Version_init() from Arguments::check_vm_args_consistency, the check for is_sun4v() always fails and the VM won't issue this warning at all. So current builds of jdk8, won't show any warning for the following java invocation (which is clearly a regression compared to jdk7):

$ java -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:+UseMemSetInBOT -version
openjdk version "1.8.0-internal"
OpenJDK Runtime Environment (build 1.8.0-internal-_2013_12_01_22_33-b00)
OpenJDK 64-Bit Server VM (build 25.0-b59, mixed mode)

So I propose the following two changes:

• Automatically reset UseMemSetInBOT if the CPU supports has_blk_init() (instead of just checking for is_niagara()) until we can be sure that memset() is implemented correctly on Fujitsu Sparc64-X CPUs
• Warn if we detect the has_blk_init() CPU feature instead of checking for is_sun4v() which may be too generic.
• Move the consistency check out of Arguments::check_vm_args_consistency into VM_Version::initialize() in vm_version_sparc.cpp. Besides the fact that all the GC flags have their final value already at that point this also has the nice effect of removing yet another #ifdef SPARC from shared code in arguments.cpp