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

[Vladimir Kozlov]

Looks good. I will take over this bug because Runtime group is very busy.

Thanks,
Vladimir

On 12/2/13 7:44 AM, Volker Simonis wrote:
> 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
>