RFR(S) Contended Locking fast enter bucket (8061553)
David Holmes
david.holmes at oracle.com
Mon Nov 3 04:44:59 UTC 2014
Hi Dan,
Looks good. Couple of nits and one semantic query below ...
src/cpu/sparc/vm/macroAssembler_sparc.cpp
Formatting changes were a bit of a distraction.
---
src/cpu/x86/vm/macroAssembler_x86.cpp
Formatting changes were a bit of a distraction.
1929 // unconditionally set stackBox->_displaced_header = 3
1930 movptr(Address(boxReg, 0),
(int32_t)intptr_t(markOopDesc::unused_mark()));
At 1870 we refer to box rather than stackBox. Also it takes some
sleuthing to realize that "3" here is somehow a pseudonym for
unused_mark(). Back up at 1808 we have a to-do:
1808 // use markOop::unused_mark() instead of "3".
so the current change seems to be implementing that, even though other
uses of "3" are left untouched.
---
src/share/vm/runtime/sharedRuntime.cpp
1794 JRT_BLOCK_ENTRY(void,
SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock*
lock, JavaThread* thread))
1795 if (!SafepointSynchronize::is_synchronizing()) {
1796 if (ObjectSynchronizer::quick_enter(_obj, thread, lock)) return;
Is it necessary to check is_synchronizing? If we are executing this code
we are not at a safepoint and the quick_enter wont change that, so I'm
not sure what we are guarding against.
---
src/share/vm/runtime/synchronizer.cpp
Minor nit: line 153 the usual acronym is NPE (for NullPointerException)
not NPX
Nit: 159 Thread * const ox
Please change ox to owner.
---
Thanks,
David
On 31/10/2014 8:50 AM, Daniel D. Daugherty wrote:
> Greetings,
>
> I have the Contended Locking fast enter bucket ready for review.
>
> The code changes in this bucket are primarily a quick_enter()
> function that works on inflated but uncontended Java monitors.
> This quick_enter() function is used on the "slow path" for Java
> Monitor enter operations when the built-in "fast path" (read
> assembly code) doesn't work.
>
> This work is being tracked by the following bug ID:
>
> JDK-8061553 Contended Locking fast enter bucket
> https://bugs.openjdk.java.net/browse/JDK-8061553
>
> Here is the webrev URL:
>
> http://cr.openjdk.java.net/~dcubed/8061553-webrev/0-jdk9-hs-rt/
>
> Here is the JEP link:
>
> https://bugs.openjdk.java.net/browse/JDK-8046133
>
> 8061553 summary of changes:
>
> macroAssembler_sparc.cpp: MacroAssembler::compiler_lock_object()
>
> - clean up spacing around some
> 'ObjectMonitor::owner_offset_in_bytes() - 2' uses
> - remove optional (EmitSync & 64) code
> - change from cmp() to andcc() so icc.zf flag is set
>
> macroAssembler_x86.cpp: MacroAssembler::fast_lock()
>
> - remove optional (EmitSync & 2) code
> - rewrite LP64 inflated lock code that tries to CAS in
> the new owner value to be more efficient
>
> interfaceSupport.hpp:
>
> - add JRT_BLOCK_NO_ASYNC to permit splitting a
> JRT_BLOCK_ENTRY into two pieces.
>
> sharedRuntime.cpp: SharedRuntime::complete_monitor_locking_C()
>
> - change entry type from JRT_ENTRY_NO_ASYNC to JRT_BLOCK_ENTRY
> to permit ObjectSynchronizer::quick_enter() call
> - add JRT_BLOCK_NO_ASYNC use if the quick_enter() doesn't work
> to revert to JRT_ENTRY_NO_ASYNC-like semantics
>
> synchronizer.[ch]pp:
>
> - add ObjectSynchronizer::quick_enter() for entering an
> inflated but unowned Java monitor without thread state
> changes
>
> Testing:
>
> - Aurora Adhoc RT/SVC baseline batch
> - JPRT test jobs
> - MonitorEnterStresser micro-benchmark (in process)
> - CallTimerGrid stress testing (in process)
> - Aurora performance testing:
> - out of the box for the "promotion" and 32-bit server configs
> - heavy weight monitors for the "promotion" and 32-bit server configs
> (-XX:-UseBiasedLocking -XX:+UseHeavyMonitors)
> (in process)
>
>
> Thanks, in advance, for any comments, questions or suggestions.
>
> Dan
More information about the hotspot-runtime-dev
mailing list