RFR: 8265933: Move Java monitor related fields from class Thread to JavaThread

[Patricio Chilano Mateo]

On Wed, 28 Apr 2021 18:58:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the following change. Fields in class Thread related to Java object monitors like _current_pending_monitor, _current_pending_monitor_is_from_java, _current_waiting_monitor and _Stalled should be moved to the JavaThread class. Members _OnTrap and _TypeTag were grouped together with _Stalled but are not used so I removed them. It seems they were part of the ObjectMonitor implementation at some point but I couldn't find how they were used.
>> Tested in mach5 tier1-2.
>> 
>> Thanks,
>> Patricio
>
> src/hotspot/share/runtime/thread.hpp line 666:
> 
>> 664: 
>> 665:  public:
>> 666:   ParkEvent * volatile _ParkEvent;            // for Object monitors, JVMTI raw monitors,
> 
> So are jvmti raw monitors not required to be taken on a Java Thread?

Hi Coleen,

> So are jvmti raw monitors not required to be taken on a Java Thread?
I thought they were, but JvmtiRawMonitor::raw_enter() has a conditional that checks whether the thread is a JavaThread or not. I looked at the generated jvmti_RawMonitorEnter() method and don't see a straightforward return for non-JavaThreads. They are rather filtered inside a conditional:


  if (Threads::number_of_threads() == 0) {
    transition = false;
  } else {
    this_thread = Thread::current_or_null();
    transition = ((this_thread != NULL) && !this_thread->is_Named_thread());
  }

  if (transition) {
    if (!this_thread->is_Java_thread()) {
      return JVMTI_ERROR_UNATTACHED_THREAD;
    }
    ... // error checking
    err = jvmti_env->RawMonitorEnter(rmonitor);
  } else {
   ... // error checking
   err = jvmti_env->RawMonitorEnter(rmonitor);
  }


If this_thread is NULL or a NamedThread I would have expected a plain return, like other jvmti methods do (e.g. jvmti_GetBytecodes):


  Thread* this_thread = Thread::current_or_null(); 
  if (this_thread == NULL || !this_thread->is_Java_thread()) {
    return JVMTI_ERROR_UNATTACHED_THREAD;
  }


Since the this_thread == NULL case should crash before getting to raw_enter() (unless we are also in the case where Threads::number_of_threads() == 0 in which case we just append the monitor to a list of pending monitors and return), that can't be the reason why raw_enter() receives Thread* instead of JavaThread*. So that leaves the NamedThread case then. I would guess that case is for the VMThread (we might call here when posting jvmti events?).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3722