changeset 18405:4a1b4400bb1f

SharedRuntime::compute_compiled_exc_handler: explain why it seems that we deoptimzie twice, use Deoptimization::deoptimize since we already have our hands on the frame.
author Gilles Duboscq <duboscq@ssw.jku.at>
date Tue, 18 Nov 2014 11:03:39 +0100
parents 03c63fd2f714
children 194041c3fdab
files src/share/vm/runtime/sharedRuntime.cpp
diffstat 1 files changed, 8 insertions(+), 2 deletions(-) [+]
line wrap: on
line diff
--- a/src/share/vm/runtime/sharedRuntime.cpp	Tue Nov 18 10:55:59 2014 +0100
+++ b/src/share/vm/runtime/sharedRuntime.cpp	Tue Nov 18 11:03:39 2014 +0100
@@ -659,11 +659,17 @@
     } else {
       // there is no exception handler for this pc => deoptimize
       nm->make_not_entrant();
+
+      // Use Deoptimization::deoptimize for all of its side-effects:
+      // revoking biases of monitors, gathering traps statistics, logging...
+      // it also patches the return pc but we do not care about that
+      // since we return a continuation to the deopt_blob below.
       JavaThread* thread = JavaThread::current();
-      RegisterMap reg_map(thread);
+      RegisterMap reg_map(thread, UseBiasedLocking);
       frame runtime_frame = thread->last_frame();
       frame caller_frame = runtime_frame.sender(&reg_map);
-      Deoptimization::deoptimize_frame(thread, caller_frame.id(), Deoptimization::Reason_not_compiled_exception_handler);
+      Deoptimization::deoptimize(thread, caller_frame, &reg_map, Deoptimization::Reason_not_compiled_exception_handler);
+
       return SharedRuntime::deopt_blob()->unpack_with_exception_in_tls();
     }
   }