RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds

[David Holmes]

Hi Martin,

On 18/09/2018 4:11 PM, Doerr, Martin wrote:
> Hi David,
> 
> thanks for doing this change.
> As written before, PPC and s390 parts look good.

Thanks for restating that here.

> Seems like os::is_MP() is unused with this change. But we're keeping it for any future use?
> I'm ok with it, just asking.

It is still used for spin-loop and related optimisations. Badly tuned 
spinloops on uniprocessors could be a significant performance issue. 
Keeping the is_MP check on a MP system is no hindrance as its just part 
of the spin-loop.

Thanks,
David

> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of Mikael Vidstedt
> Sent: Dienstag, 18. September 2018 08:07
> To: David Holmes <david.holmes at oracle.com>
> Cc: hotspot-dev developers <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds
> 
> 
> Nice cleanup, looks good!
> 
> Minor nit:
> 
> sharedRuntime_x86_32.cpp: two right brackets on the same line (2102).
> 
> Cheers,
> Mikael
> 
>> On Sep 17, 2018, at 10:32 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764
>> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/
>>
>> As previously discussed in the RFC thread:
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html
>>
>> this change obsoletes the AssumeMP flag and removes the bulk of the logic that is conditional on os::is_MP() as follows:
>>
>> 1. to gate the introduction of MP-specific features, notably memory barriers
>>
>> The is_MP check is removed and we will always issue memory barriers
>> or pre-pend lock prefix etc.
>>
>> 2. to align certain patchable code sequences (method entry, call sites)
>>
>> The is_MP is removed and we always align patchable locations.
>>
>> 3. to gate certain optimizations which are questionable on uniprocessors
>> (see quicken_jni_functions)
>>
>> These are psuedo-memory-barriers where we manufacture a data-dependency
>> instead of inserting mfence/lfence (x86 example). These are treated as
>> #1 and is_MP is removed.
>>
>> 4. to gate optimizations which are desirable on uniprocessors
>> (mutex/monitor short circuits)
>>
>> These are spin controls and so is_MP remains.
>>
>> I have not updated the about-to-be-removed Oracle ARM port code.
>>
>> Testing:
>>   - Tiers 1 -3 (mach5)
>>
>> Performance run TBD.
>>
>> Thanks,
>> David
>