RFR(S) Contended Locking fast exit bucket (8073165)
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed Apr 8 20:35:43 UTC 2015
On 3/13/15 8:05 AM, Aleksey Shipilev wrote:
> On 03/13/2015 07:50 AM, David Holmes wrote:
>>> - remove old mfence() support
>> So I had expected to see this change conditional on the runtime
>> processor type. But then I checked Dave's blog and saw this was
>> determined 5+ years ago (!!!) so those older processors are no longer a
>> consideration. I do hope the performance tests have been re-run since
>> then though ;-)
> MFENCE still has stronger ordering guarantees, and LOCK'ed instructions
> are faster for regular accesses. Note that we also observed the
> performance effects when doing blind "lock addl %(rsp), 0":
> https://bugs.openjdk.java.net/browse/JDK-8050147
> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/51e474c55d20
> http://shipilev.net/blog/2014/on-the-fence-with-dependencies/
>
> Thanks,
> -Aleksey.
>
I addressed this part of David H's comment in my reply to him:
> I do hope the performance tests have been re-run since
> then though ;-)
I should have been more clear with my summary line:
> - remove old mfence() support
Here's the complete diff for that part of the code:
@@ -2124,16 +2109,12 @@
// We currently use (3), although it's likely that switching to (2)
// is correct for the future.
movptr(Address(tmpReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)),
NULL_WORD);
if (os::is_MP()) {
- if (VM_Version::supports_sse2() && 1 == FenceInstruction) {
- mfence();
- } else {
- lock (); addptr(Address(rsp, 0), 0);
+ lock(); addptr(Address(rsp, 0), 0);
}
- }
// Ratify _succ remains non-null
cmpptr(Address(tmpReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(succ)), 0);
jccb (Assembler::notZero, LSuccess);
xorptr(boxReg, boxReg); // box is really EAX
We only used the mfence() instruction when the FenceInstruction
was enabled and VM_Version::supports_sse2() == true.
Here's the rgrep for FenceInstruction:
$ rgrep FenceInstruction src
src/cpu/x86/vm/globals_x86.hpp: product(intx, FenceInstruction,
0, \
src/cpu/x86/vm/macroAssembler_x86.cpp: if
(VM_Version::supports_sse2() && 1 == FenceInstruction) {
so the option is disabled by default and by removing the fence()
in this bucket, I'm removing the last (and only?) use of the
option. I'm going to need a CCC request for removing the flag...
and I was hoping to get through this project without any CCC
requests...
The FenceInstruction option appeared here:
$ sp -r1.956.1.1 src/share/vm/runtime/globals.hpp
src/share/vm/runtime/SCCS/s.globals.hpp:
D 1.956.1.1 07/03/09 17:40:52 dice 3486 3482 00002/00003/03062
MRs:
COMMENTS:
6468954 : minor clean up
$ sccs sccsdiff -r1.956 -r1.956.1.1 src/share/vm/runtime/globals.hpp
------- globals.hpp -------
727c727
< product(intx, EmitLFence,
0, \
---
> product(intx, FenceInstruction,
0, \
2720,2721c2720
< product(bool, UseThreadPriorities,
true, \
< "Use native thread
priorities") \
---
> product_pd(bool, UseThreadPriorities, "Use native thread
priorities") \
so the option used to be named 'EmitLFence'. That option
was introduced by this delta:
$ sp -r1.904.2.1 src/share/vm/runtime/globals.hpp
src/share/vm/runtime/SCCS/s.globals.hpp:
D 1.904.2.1 05/11/19 16:17:32 dice 3379 3375 00003/00000/02794
MRs:
COMMENTS:
6320199: improve code density for inline synchronization operations
$ sccs sccsdiff -r1.904 -r1.904.2.1 src/share/vm/runtime/globals.hpp
------- globals.hpp -------
651a652,654
> product(intx, EmitLFence,
0, \
> "(Unsafe,Unstable) Experimental")
So the EmitLFence was introduced in JDK6-B70 and has
always been disabled by default. I think it's safe to
say that generating the mfence() has been out of the
default code base for a long time.
I'm planning to stick with the removal of the mfence()
and I'll also get rid of the FenceInstruction option.
BTW, here's the complete entry for the option:
src/cpu/x86/vm/globals_x86.hpp:
product(intx, FenceInstruction,
0, \
"(Unsafe,Unstable)
Experimental") \
Looks like I missed changing the option from product(...)
to experimental(...) back in the cleanup bucket...
David H and/or Aleksey, please let me know if either of you
has any objections to this resolution.
Dan
More information about the hotspot-runtime-dev
mailing list