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