RFR(S): 8029190 : VM_Version::determine_features() asserts on Fujitsu Sparc64 CPUs

[Volker Simonis]

Hi,

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 following small webrev
tries to address this problem:

http://cr.openjdk.java.net/~simonis/webrevs/8029190/

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

As always, I need a reviewer and a sponsor for pushing.

Thank you and best regards,
Volker