Re: [RFA] Suspend counting for JDWP

[Keith Seitz <keiths at redhat dot com>]

Bryce McKinlay wrote:

> I wonder if it is worthwhile to maintain a suspend_count_mutex for every 
> thread, particularly when it will only be needed during debugging 
> sessions. Perhaps a single, global mutex is sufficient?

It could be. Hadn't thought about that. I've attached a new patch which 
does this.

> Are we likely to need to associate other JVMTI/JDWP debugging data with 
> a thread? If so then it might be wise to put these in a 
> _Jv_ThreadDebugInfo (or some such) struct which would be initialized 
> only when JDWP is in use.

JVMTI defines the following thread-related functions:

    * Get Thread State
    * Get All Threads
    * Suspend Thread
    * Suspend Thread List
    * Resume Thread
    * Resume Thread List
    * Stop Thread
    * Interrupt Thread
    * Get Thread Info
    * Get Owned Monitor Info
    * Get Current Contended Monitor
    * Run Agent Thread
    * Set Thread Local Storage
    * Get Thread Local Storage

All of these things basically mirror JDWP information, and all of it is 
contained within the thread. JVMTI does not give access to suspend 
counts the way JDWP does.

> If we had that, these suspend functions could be made "generic" - put in 
> a jvmti.cc or some such, and we'd only need a _Jv_GetThreadDebugInfo in 
> posix-threads.h/win32-threads.h.

Of course, nothing stops us from implementing JVMTI right along with 
JDWP, since the two do obviously overlap in many ways. But that was well 
outside the scope of the project.

If we wanted to add JVMTI support for thread suspend/resume, it would be 
pretty simple using either _Jv_DebugSuspendThread or _Jv_SuspendThread, 
depending on whether we were going to use suspend counts.

JVMTI defines a GetThreadInfo function which returns the following 
structure:

typedef struct {
    char* name;
    jint priority;
    jboolean is_daemon;
    jthreadGroup thread_group;
    jobject context_class_loader;
} jvmtiThreadInfo;

As you can see, all of this is already readily available.

So, the question is: do maintainers want to start implementing JVMTI and 
switch over to use it now or wait and implement the whole thing? I'm 
sure that these threading issues are not the only place this route could 
have been chosen.

Alas, this is a choice which is not mine to make. I always saw JVMTI as 
a separate, follow-on project (hopefully mine, too).

Keith