RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds

David Holmes david.holmes at oracle.com
Fri Sep 14 00:10:30 UTC 2018


Bug: https://bugs.openjdk.java.net/browse/JDK-8188764

Further to the discussion on this under "8185062: os::is_MP() sometimes 
returns false":

http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-August/027720.html

then:

http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-March/031038.html

I've recommenced working on this for JDK 12.

John identifies 4 different uses of os::is_MP in the bug report which I 
plan to address as follows:

1. to gate the introduction of MP-specific features, notably memory barriers

The is_MP check will be 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 currently retained. This is because I have no idea what 
this alignment logic is or how it relates to uniprocessor or 
multiprocessor implementations. Can anyone shed some light?

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.

There's an initial partial webrev (mainly x86):

http://cr.openjdk.java.net/~dholmes/8188764/webrev/

Comments welcome.

Thanks,
David


More information about the hotspot-dev mailing list