RFC: 8185062: os::is_MP() sometimes returns false
shade at redhat.com
Wed Aug 2 09:00:09 UTC 2017
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  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
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 .
> 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.
More information about the hotspot-dev