RFR(m): 8221734: Deoptimize with handshakes

Daniel D. Daugherty daniel.daugherty at oracle.com
Thu Apr 25 20:43:22 UTC 2019


On 4/25/19 8:05 AM, Robbin Ehn wrote:
> Hi all, please review.
>
> Let's deopt with handshakes.
> Removed VM op Deoptimize, instead we handshake.
> Locks needs to be inflate since we are not in a safepoint.
>
> Goes on top of:
> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-April/033491.html 
>
>
> Code:
> http://cr.openjdk.java.net/~rehn/8221734/v1/webrev/index.html

Robbin, you'll have to merge with Coleen's recent MutexLocker fix (8222518).

src/hotspot/share/aot/aotCodeHeap.cpp
     No comments.

src/hotspot/share/aot/aotCompiledMethod.cpp
     L163: bool AOTCompiledMethod::make_not_entrant_helper(int new_state) {
     L207: bool AOTCompiledMethod::make_entrant() {
         So the Compiler team is on board with switching from the
         Patching_lock to the CompiledMethod_lock?

src/hotspot/share/code/codeCache.cpp
     No comments.

src/hotspot/share/code/nmethod.cpp
     L1180: bool nmethod::make_not_entrant_or_zombie(int state) {
     L2853: void nmethod::clear_jvmci_installed_code() {
     L2861: void nmethod::clear_speculation_log() {
     L2869: void nmethod::maybe_invalidate_installed_code() {
     L2904: void nmethod::invalidate_installed_code(Handle 
installedCode, TRAPS) {
         So the Compiler team is on board with switching from the
         Patching_lock to the CompiledMethod_lock?

src/hotspot/share/code/nmethod.hpp
     No comments.

src/hotspot/share/gc/z/zBarrierSetNMethod.cpp
     No comments (copyright year needs update).

src/hotspot/share/gc/z/zNMethod.cpp
     No comments (copyright year needs update).

src/hotspot/share/oops/markOop.hpp
     L180:   bool biased_locker_is(JavaThread* thread) const {
         Is this for a different project?

     L181:     if (!has_bias_pattern()) {
     L182:       return false;
     L183:     }
     L184:     // If current thread is not the owner it can be unbiased 
at anytime.
     L185:     JavaThread* jt = (JavaThread*) ((intptr_t) 
(mask_bits(value(), ~(biased_lock_mask_in_place | age_mask_in_place | 
epoch_mask_in_place))));
         So you don't want to use this:

           JavaThread* biased_locker() const {
             assert(has_bias_pattern(), "should not call this otherwise");
             return (JavaThread*) ((intptr_t) (mask_bits(value(), 
~(biased_lock_mask_in_place | age_mask_in_place | epoch_mask_in_place))));
           }

         because of the assert().

         I think biased_locker() and biased_locker_is() both need to work
         with a copy of the markOop so that it can't change dynamically.
         Something like:

           JavaThread* biased_locker() const {
             markOop copy = this;
             assert(copy.has_bias_pattern(), "should not call this 
otherwise");
             return (JavaThread*) ((intptr_t) (copy.mask_bits(value(), 
~(biased_lock_mask_in_place | age_mask_in_place | epoch_mask_in_place))));
           }

           bool biased_locker_is(JavaThread* thread) const {
             markOop copy = this;
             if (!copy.has_bias_pattern()) {
               return false;
             }
             return copy.biased_locker();
           }

src/hotspot/share/oops/method.cpp
     old L104:   clear_code(false /* don't need a lock */); // 
from_c/from_i get set to c2i/i2i
         Is the comment after '//' not useful?

     L946:     MutexLockerEx ml(CompiledMethod_lock->owned_by_self() ? 
NULL : CompiledMethod_lock, Mutex::_no_safepoint_check_flag);
         So the Compiler team is on board with switching from the
         Patching_lock to the CompiledMethod_lock?

src/hotspot/share/oops/method.hpp
     No comments.

src/hotspot/share/prims/jvmtiEventController.cpp
     No comments (copyright year needs update).

src/hotspot/share/prims/methodHandles.cpp
     No comments.

src/hotspot/share/prims/whitebox.cpp
     No comments.

src/hotspot/share/runtime/biasedLocking.cpp
src/hotspot/share/runtime/biasedLocking.hpp
     Hmmm... More Biased Locking changes. I didn't take a close
     look at these.

src/hotspot/share/runtime/deoptimization.cpp
     No comments (but some overlap with Biased Locking, ouch)

src/hotspot/share/runtime/deoptimization.hpp
     No comments.

src/hotspot/share/runtime/mutex.hpp
     old L65:        special        = tty            +   1,
     new L65:        special        = tty            +   2,
         Why?

src/hotspot/share/runtime/mutexLocker.cpp
     No comments.

src/hotspot/share/runtime/mutexLocker.hpp
     L34: extern Mutex*   Patching_lock;                   // a lock 
used to guard code patching of compiled code
     L35: extern Mutex*   CompiledMethod_lock;
         A comment is traditional here...

src/hotspot/share/runtime/synchronizer.cpp
     old L1317:          !SafepointSynchronize::is_at_safepoint(), 
"invariant");
     new L1317:          !Universe::heap()->is_gc_active(), "invariant");
         Why?

     L1446:         ResourceMark rm;
     L1496:       ResourceMark rm;
         Why drop 'Self'? That makes the ResourceMark more expensive..

src/hotspot/share/runtime/thread.cpp
     No comments.

src/hotspot/share/runtime/thread.hpp
     No comments.

src/hotspot/share/runtime/vmOperations.cpp
     No comments.

src/hotspot/share/runtime/vmOperations.hpp
     No comments.

src/hotspot/share/services/dtraceAttacher.cpp
     No comments (copyright year needs update).


I don't think I've found anything that's "must fix". Please let me know
if I should re-review:

     src/hotspot/share/runtime/biasedLocking.cpp
     src/hotspot/share/runtime/biasedLocking.hpp
     src/hotspot/share/runtime/deoptimization.cpp

because the Biased Locking changes are critical for this project.

Dan


> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8221734
>
> Passes t1-7 and multiple t1-5 runs.
>
> A few startup benchmark see a small speedup.
>
> Thanks, Robbin



More information about the hotspot-compiler-dev mailing list