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

David Holmes david.holmes at oracle.com
Wed Sep 19 06:47:28 UTC 2018


 > I have not updated the about-to-be-removed Oracle ARM port code.

It is only the 64-bit port that is being removed so I do need to look at 
the other ARM code. This may get more awkward given we only support MP 
ARM on v6 and v7, and that some v7 variants don't support MP.

David

On 18/09/2018 3:32 PM, David Holmes 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


More information about the hotspot-dev mailing list