RFC: 8185062: os::is_MP() sometimes returns false

[Aleksey Shipilev]

On 08/02/2017 06:35 AM, David Holmes wrote:
> Does anyone care about uniprocessor systems _and_ care to the extent that the overhead of things
> only necessary on MP systems (_lock prefixes, explicit atomic instructions, memory barriers) would
> be a problem?

Very happy to see os::is_MP phased out and go. Performance-wise, as the experience with expunging
is_MP from Atomics [1] shows, there is a benefit for MP systems with expunging is_MP checks from
native code paths. My only concern is with low-power single-processor ARMs and MIPSes. Looking
around HS codebase, I think only that matters now.

> As outlined in the "bug" report there are three basic options:
> 
> 1. Switch AssumeMP to be true by default (arguably necessary regardless due to dynamic container
> environments)

FWIW, we (Red Hat) are shipping our RPMs with AssumeMP switched to "true" by default [2, 3], because
of the container issues. Recent glibc helps there too [4].

> 2. Allow non-MP support to be built, but by default only build MP support ie no runtime means to
> disable MP support, and compile-time MP_ONLY/NOT_MP macros.
> 3. Assume the universe is MP and only allow MP to be built

On the fence between these two. Completely fine with removing is_MP from the native codepaths,
because that yields benefits for others. Kinda see the reason to keep is_MP checks/macros in the
compiler code, to claim the benefits on lower ARMs and MIPSes.

Thanks,
-Aleksey


[1] https://bugs.openjdk.java.net/browse/JDK-8169061
[2] https://git.centos.org/blob/rpms!java-1.8.0-openjdk.git/c7/SOURCES!always_assumemp.patch
[3] https://git.centos.org/blob/rpms!java-1.8.0-openjdk.git/c7/SPECS!java-1.8.0-openjdk.spec#L963
[4] https://sourceware.org/ml/libc-alpha/2017-06/msg00101.html