< prev index next >

src/hotspot/share/services/threadService.cpp

Print this page
rev 60098 : 8246476: remove AsyncDeflateIdleMonitors option and the safepoint based deflation mechanism
Reviewed-by: dholmes, pchilanomate, coleenp


 205 
 206 // FIXME: JVMTI should call this function
 207 Handle ThreadService::get_current_contended_monitor(JavaThread* thread) {
 208   assert(thread != NULL, "should be non-NULL");
 209   debug_only(Thread::check_for_dangling_thread_pointer(thread);)
 210 
 211   // This function can be called on a target JavaThread that is not
 212   // the caller and we are not at a safepoint. So it is possible for
 213   // the waiting or pending condition to be over/stale and for the
 214   // first stage of async deflation to clear the object field in
 215   // the ObjectMonitor. It is also possible for the object to be
 216   // inflated again and to be associated with a completely different
 217   // ObjectMonitor by the time this object reference is processed
 218   // by the caller.
 219   ObjectMonitor *wait_obj = thread->current_waiting_monitor();
 220 
 221   oop obj = NULL;
 222   if (wait_obj != NULL) {
 223     // thread is doing an Object.wait() call
 224     obj = (oop) wait_obj->object();
 225     assert(AsyncDeflateIdleMonitors || obj != NULL, "Object.wait() should have an object");
 226   } else {
 227     ObjectMonitor *enter_obj = thread->current_pending_monitor();
 228     if (enter_obj != NULL) {
 229       // thread is trying to enter() an ObjectMonitor.
 230       obj = (oop) enter_obj->object();
 231       assert(AsyncDeflateIdleMonitors || obj != NULL, "ObjectMonitor should have an associated object!");
 232     }
 233   }
 234 
 235   Handle h(Thread::current(), obj);
 236   return h;
 237 }
 238 
 239 bool ThreadService::set_thread_monitoring_contention(bool flag) {
 240   MutexLocker m(Management_lock);
 241 
 242   bool prev = _thread_monitoring_contention_enabled;
 243   _thread_monitoring_contention_enabled = flag;
 244 
 245   return prev;
 246 }
 247 
 248 bool ThreadService::set_thread_cpu_time_enabled(bool flag) {
 249   MutexLocker m(Management_lock);
 250 
 251   bool prev = _thread_cpu_time_enabled;




 205 
 206 // FIXME: JVMTI should call this function
 207 Handle ThreadService::get_current_contended_monitor(JavaThread* thread) {
 208   assert(thread != NULL, "should be non-NULL");
 209   debug_only(Thread::check_for_dangling_thread_pointer(thread);)
 210 
 211   // This function can be called on a target JavaThread that is not
 212   // the caller and we are not at a safepoint. So it is possible for
 213   // the waiting or pending condition to be over/stale and for the
 214   // first stage of async deflation to clear the object field in
 215   // the ObjectMonitor. It is also possible for the object to be
 216   // inflated again and to be associated with a completely different
 217   // ObjectMonitor by the time this object reference is processed
 218   // by the caller.
 219   ObjectMonitor *wait_obj = thread->current_waiting_monitor();
 220 
 221   oop obj = NULL;
 222   if (wait_obj != NULL) {
 223     // thread is doing an Object.wait() call
 224     obj = (oop) wait_obj->object();

 225   } else {
 226     ObjectMonitor *enter_obj = thread->current_pending_monitor();
 227     if (enter_obj != NULL) {
 228       // thread is trying to enter() an ObjectMonitor.
 229       obj = (oop) enter_obj->object();

 230     }
 231   }
 232 
 233   Handle h(Thread::current(), obj);
 234   return h;
 235 }
 236 
 237 bool ThreadService::set_thread_monitoring_contention(bool flag) {
 238   MutexLocker m(Management_lock);
 239 
 240   bool prev = _thread_monitoring_contention_enabled;
 241   _thread_monitoring_contention_enabled = flag;
 242 
 243   return prev;
 244 }
 245 
 246 bool ThreadService::set_thread_cpu_time_enabled(bool flag) {
 247   MutexLocker m(Management_lock);
 248 
 249   bool prev = _thread_cpu_time_enabled;


< prev index next >