[RFA] Add JDWP VM_INIT JVMTI callback

[RFA] Add JDWP VM_INIT JVMTI callback

[Keith Seitz]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

Hi,

This patch adds a JVMTI VM_INIT callback to be used by the JDWP code. 
Currently this function simply sends the JDWP VM_INIT event 
notification, but later it will do install additional JVMTI callbacks 
for all the various JDWP event notifications.

Comments/questions/concerns?
Keith

ChangeLog
2007-01-15  Keith Seitz  <keiths@redhat.com>

         * gnu/classpath/jdwp/natVMVirtualMachine.cc (DEFINE_CALLBACK): 
New macro.
         (ENABLE_EVENT): New macro.
         (initialize): Define and enable JVMTI VM_INIT callback.
         (jdwpVMInitCB): New function.

[-- Attachment #2: vminitcb.patch --]
[-- Type: text/x-patch, Size: 2008 bytes --]

Index: gnu/classpath/jdwp/natVMVirtualMachine.cc
===================================================================
--- gnu/classpath/jdwp/natVMVirtualMachine.cc	(revision 120805)
+++ gnu/classpath/jdwp/natVMVirtualMachine.cc	(working copy)
@@ -24,10 +24,12 @@
 #include <java/util/Hashtable.h>
 #include <java/util/Iterator.h>
 
+#include <gnu/classpath/jdwp/Jdwp.h>
 #include <gnu/classpath/jdwp/VMFrame.h>
 #include <gnu/classpath/jdwp/VMMethod.h>
 #include <gnu/classpath/jdwp/VMVirtualMachine.h>
 #include <gnu/classpath/jdwp/event/EventRequest.h>
+#include <gnu/classpath/jdwp/event/VmInitEvent.h>
 #include <gnu/classpath/jdwp/exception/JdwpInternalErrorException.h>
 #include <gnu/classpath/jdwp/util/MethodResult.h>
 
@@ -35,6 +37,13 @@
 using namespace gnu::classpath::jdwp::event;
 using namespace gnu::classpath::jdwp::util;
 
+// Forward declarations
+static void jdwpVMInitCB (jvmtiEnv *env, JNIEnv *jni_env, jthread thread);
+
+#define DEFINE_CALLBACK(Cb,Event) Cb.Event = jdwp ## Event ## CB
+#define ENABLE_EVENT(Event,Thread)					\
+  _jdwp_jvmtiEnv->SetEventNotificationMode (JVMTI_ENABLE,		\
+					    JVMTI_EVENT_ ## Event, Thread)
 // JVMTI environment
 static jvmtiEnv *_jdwp_jvmtiEnv;
 
@@ -44,6 +53,12 @@
   _jdwp_suspend_counts = new ::java::util::Hashtable ();
   JavaVM *vm = _Jv_GetJavaVM ();
   vm->GetEnv (reinterpret_cast<void **> (&_jdwp_jvmtiEnv), JVMTI_VERSION_1_0);
+
+  // Wait for VM_INIT to do more initialization
+  jvmtiEventCallbacks callbacks;
+  DEFINE_CALLBACK (callbacks, VMInit);
+  _jdwp_jvmtiEnv->SetEventCallbacks (&callbacks, sizeof (callbacks));
+  ENABLE_EVENT (VM_INIT, NULL);
 }
 
 void
@@ -343,3 +358,13 @@
 {
   return NULL;
 }
+
+static void
+jdwpVMInitCB (MAYBE_UNUSED jvmtiEnv *env, MAYBE_UNUSED JNIEnv *jni_env,
+	      jthread thread)
+{
+  // Send JDWP VMInit
+  using namespace gnu::classpath::jdwp::event;
+  Thread *init_thread = reinterpret_cast<Thread *> (thread);
+  gnu::classpath::jdwp::Jdwp::notify (new VmInitEvent (init_thread));
+}

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:

Keith> This patch adds a JVMTI VM_INIT callback to be used by the JDWP
Keith> code. Currently this function simply sends the JDWP VM_INIT event
Keith> notification, but later it will do install additional JVMTI callbacks
Keith> for all the various JDWP event notifications.

Keith> Comments/questions/concerns?

Ok, thanks.

Tom

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Keith Seitz]

Tom Tromey wrote:
> Ok, thanks.

Done. Thank you for taking a look.

Keith

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Marco Trudel]

[-- Attachment #1: Type: text/plain, Size: 8922 bytes --]

Keith Seitz wrote:
> Hi,
> 
> This patch adds a JVMTI VM_INIT callback to be used by the JDWP code. 
> Currently this function simply sends the JDWP VM_INIT event 
> notification, but later it will do install additional JVMTI callbacks 
> for all the various JDWP event notifications.
> 
> Comments/questions/concerns?

This breaks at least cross-compilation for host=Linux target=minGW:
/home/Marco/Desktop/compile-lin-win/gcc-build/./gcc/xgcc -shared-libgcc 
-B/home/Marco/Desktop/compile-lin-win/gcc-build/./gcc -nostdinc++ 
-L/home/Marco/Desktop/compile-lin-win/gcc-build/i686-pc-mingw32/libstdc++-v3/src 
-L/home/Marco/Desktop/compile-lin-win/gcc-build/i686-pc-mingw32/libstdc++-v3/src/.libs 
-L/home/Marco/Desktop/compile-lin-win/gcc-build/i686-pc-mingw32/winsup/mingw 
-L/home/Marco/Desktop/compile-lin-win/gcc-build/i686-pc-mingw32/winsup/w32api/lib 
-isystem /usr/local/src/gcc/winsup/mingw/include -isystem 
/usr/local/src/gcc/winsup/w32api/include 
-B/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/i686-pc-mingw32/bin/ 
-B/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/i686-pc-mingw32/lib/ 
-isystem 
/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/i686-pc-mingw32/include 
-isystem 
/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/i686-pc-mingw32/sys-include 
-DHAVE_CONFIG_H -I. -I/usr/local/src/gcc/libjava -I./include -I./gcj 
-I/usr/local/src/gcc/libjava -Iinclude 
-I/usr/local/src/gcc/libjava/include 
-I/usr/local/src/gcc/libjava/classpath/include -Iclasspath/include 
-I/usr/local/src/gcc/libjava/classpath/native/fdlibm 
-I/usr/local/src/gcc/libjava/../boehm-gc/include -I../boehm-gc/include 
-I/usr/local/src/gcc/libjava/libltdl 
-I/usr/local/src/gcc/libjava/libltdl 
-I/usr/local/src/gcc/libjava/.././libjava/../gcc 
-I/usr/local/src/gcc/libjava/../zlib 
-I/usr/local/src/gcc/libjava/../libffi/include -I../libffi/include 
-fno-rtti -fnon-call-exceptions -mthreads -fdollars-in-identifiers 
-Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer 
-fno-omit-frame-pointer -Wextra -Wall -D_GNU_SOURCE 
-DPREFIX=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win\" 
-DTOOLEXECLIBDIR=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/i686-pc-mingw32/lib\" 
-DJAVA_HOME=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win\" 
-DBOOT_CLASS_PATH=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/share/java/libgcj-4.3.0.jar\" 
-DJAVA_EXT_DIRS=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/share/java/ext\" 
-DGCJ_ENDORSED_DIRS=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/share/java/gcj-endorsed\" 
-DGCJ_VERSIONED_LIBDIR=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/lib/gcj-4.3.0\" 
-DPATH_SEPARATOR=\":\" 
-DLIBGCJ_DEFAULT_DATABASE=\"/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/lib/gcj-4.3.0/classmap.db\" 
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.3.0/classmap.db\" -g -O2 
--sysroot=/home/Marco/Desktop/compile-lin-win/gcc-XYZXYZ-win/sys-root 
-MT gnu/classpath/jdwp/natVMVirtualMachine.lo -MD -MP -MF 
gnu/classpath/jdwp/.deps/natVMVirtualMachine.Tpo -c 
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc -o 
gnu/classpath/jdwp/natVMVirtualMachine.o
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc: In 
static member function 'static void 
gnu::classpath::jdwp::VMVirtualMachine::initialize()':
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:55: 
warning: dereferencing type-punned pointer will break strict-aliasing rules
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:59: 
error: invalid conversion from 'void (*)(jvmtiEnv*, JNIEnv*, 
java::lang::Object*)' to 'void (*)(jvmtiEnv*, JNIEnv*, java::lang::Object*)'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc: At 
global scope:
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:278: 
warning: unused parameter 'kind'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:295: 
warning: unused parameter 'klass'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:301: 
warning: unused parameter 'klass'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:307: 
warning: unused parameter 'klass'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:307: 
warning: unused parameter 'id'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:315: 
warning: unused parameter 'thread'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:315: 
warning: unused parameter 'start'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:315: 
warning: unused parameter 'length'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:322: 
warning: unused parameter 'thread'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:322: 
warning: unused parameter 'bb'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:328: 
warning: unused parameter 'thread'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:334: 
warning: unused parameter 'thread'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:340: 
warning: unused parameter 'cl'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:351: 
warning: unused parameter 'obj'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:351: 
warning: unused parameter 'thread'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:351: 
warning: unused parameter 'clazz'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:351: 
warning: unused parameter 'method'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:351: 
warning: unused parameter 'values'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:351: 
warning: unused parameter 'nonVirtual'
/usr/local/src/gcc/libjava/gnu/classpath/jdwp/natVMVirtualMachine.cc:357: 
warning: unused parameter 'clazz'
make[3]: *** [gnu/classpath/jdwp/natVMVirtualMachine.lo] Error 1
make[3]: Leaving directory 
`/home/Marco/Desktop/compile-lin-win/gcc-build/i686-pc-mingw32/libjava'


Attached my proposed patch to fix it. Once again a forgotten "JNICALL". 
Please guys, remember the JNICALLs! They're not necessary for Linux but 
at least minGW needs them...

Changelog:
	* gnu/classpath/jdwp/natVMVirtualMachine.cc
	(jdwpVMInitCB):	Added forgotten "JNICALL"


Marco

> Keith
> 
> ChangeLog
> 2007-01-15  Keith Seitz  <keiths@redhat.com>
> 
>         * gnu/classpath/jdwp/natVMVirtualMachine.cc (DEFINE_CALLBACK): 
> New macro.
>         (ENABLE_EVENT): New macro.
>         (initialize): Define and enable JVMTI VM_INIT callback.
>         (jdwpVMInitCB): New function.
> 
> 
> ------------------------------------------------------------------------
> 
> Index: gnu/classpath/jdwp/natVMVirtualMachine.cc
> ===================================================================
> --- gnu/classpath/jdwp/natVMVirtualMachine.cc	(revision 120805)
> +++ gnu/classpath/jdwp/natVMVirtualMachine.cc	(working copy)
> @@ -24,10 +24,12 @@
>  #include <java/util/Hashtable.h>
>  #include <java/util/Iterator.h>
>  
> +#include <gnu/classpath/jdwp/Jdwp.h>
>  #include <gnu/classpath/jdwp/VMFrame.h>
>  #include <gnu/classpath/jdwp/VMMethod.h>
>  #include <gnu/classpath/jdwp/VMVirtualMachine.h>
>  #include <gnu/classpath/jdwp/event/EventRequest.h>
> +#include <gnu/classpath/jdwp/event/VmInitEvent.h>
>  #include <gnu/classpath/jdwp/exception/JdwpInternalErrorException.h>
>  #include <gnu/classpath/jdwp/util/MethodResult.h>
>  
> @@ -35,6 +37,13 @@
>  using namespace gnu::classpath::jdwp::event;
>  using namespace gnu::classpath::jdwp::util;
>  
> +// Forward declarations
> +static void jdwpVMInitCB (jvmtiEnv *env, JNIEnv *jni_env, jthread thread);
> +
> +#define DEFINE_CALLBACK(Cb,Event) Cb.Event = jdwp ## Event ## CB
> +#define ENABLE_EVENT(Event,Thread)					\
> +  _jdwp_jvmtiEnv->SetEventNotificationMode (JVMTI_ENABLE,		\
> +					    JVMTI_EVENT_ ## Event, Thread)
>  // JVMTI environment
>  static jvmtiEnv *_jdwp_jvmtiEnv;
>  
> @@ -44,6 +53,12 @@
>    _jdwp_suspend_counts = new ::java::util::Hashtable ();
>    JavaVM *vm = _Jv_GetJavaVM ();
>    vm->GetEnv (reinterpret_cast<void **> (&_jdwp_jvmtiEnv), JVMTI_VERSION_1_0);
> +
> +  // Wait for VM_INIT to do more initialization
> +  jvmtiEventCallbacks callbacks;
> +  DEFINE_CALLBACK (callbacks, VMInit);
> +  _jdwp_jvmtiEnv->SetEventCallbacks (&callbacks, sizeof (callbacks));
> +  ENABLE_EVENT (VM_INIT, NULL);
>  }
>  
>  void
> @@ -343,3 +358,13 @@
>  {
>    return NULL;
>  }
> +
> +static void
> +jdwpVMInitCB (MAYBE_UNUSED jvmtiEnv *env, MAYBE_UNUSED JNIEnv *jni_env,
> +	      jthread thread)
> +{
> +  // Send JDWP VMInit
> +  using namespace gnu::classpath::jdwp::event;
> +  Thread *init_thread = reinterpret_cast<Thread *> (thread);
> +  gnu::classpath::jdwp::Jdwp::notify (new VmInitEvent (init_thread));
> +}


[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 777 bytes --]

Index: gnu/classpath/jdwp/natVMVirtualMachine.cc
===================================================================
--- gnu/classpath/jdwp/natVMVirtualMachine.cc	(revision 120933)
+++ gnu/classpath/jdwp/natVMVirtualMachine.cc	(working copy)
@@ -38,7 +38,7 @@
 using namespace gnu::classpath::jdwp::util;
 
 // Forward declarations
-static void jdwpVMInitCB (jvmtiEnv *env, JNIEnv *jni_env, jthread thread);
+static void JNICALL jdwpVMInitCB (jvmtiEnv *env, JNIEnv *jni_env, jthread thread);
 
 #define DEFINE_CALLBACK(Cb,Event) Cb.Event = jdwp ## Event ## CB
 #define ENABLE_EVENT(Event,Thread)					\
@@ -359,7 +359,7 @@
   return NULL;
 }
 
-static void
+static void JNICALL
 jdwpVMInitCB (MAYBE_UNUSED jvmtiEnv *env, MAYBE_UNUSED JNIEnv *jni_env,
 	      jthread thread)
 {

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Keith Seitz]

Marco Trudel wrote:


> Please guys, remember the JNICALLs! They're not necessary for Linux but 
> at least minGW needs them...

Ugh, you know, and I really WAS being careful about that... I 
double-checked that all my functions did that -- all the JVMTI ones, at 
least. Sigh.

Very sorry about that.

Keith

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Andrew Haley]

Marco Trudel writes:
 > Keith Seitz wrote:
 > > Hi,
 > > 
 > > This patch adds a JVMTI VM_INIT callback to be used by the JDWP code. 
 > > Currently this function simply sends the JDWP VM_INIT event 
 > > notification, but later it will do install additional JVMTI callbacks 
 > > for all the various JDWP event notifications.
 > > 
 > > Comments/questions/concerns?

Keith: as well as Marco's fixes, please fix your warnings.

Andrew.

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Keith Seitz]

[-- Attachment #1: Type: text/plain, Size: 866 bytes --]

Andrew Haley wrote:

> Keith: as well as Marco's fixes, please fix your warnings.

Okay, I've committed Marco's fix.

Here's a patch which removes the warnings and does some reformatting of 
the long lines (and other really minor whitespace stuff that indent found).

However, it contains a lot of method decls like:

jint
gnu::classpath::jdwp::
some_method (MAYBE_UNUSED type1 argument1, MAYBE_UNUSED type2 argument2,
              MAYBE_UNUSED type3 argument3)
{
   // ...
}

and such. Indent was very inconsistent about how to format some of these 
lines, so I chose the one I thought looked the best.

Any suggestions on how to clean these long lines up better or is this 
sufficient?

Keith

ChangeLog

2007-01-18  Keith Seitz  <keiths@redhat.com>

         * gnu/classpath/jdwp/natVMVirtualMachine.cc: Mark unused 
parameters in
         methods and reformat.

[-- Attachment #2: natvmvm-reformat.patch --]
[-- Type: text/x-patch, Size: 3671 bytes --]

Index: gnu/classpath/jdwp/natVMVirtualMachine.cc
===================================================================
--- gnu/classpath/jdwp/natVMVirtualMachine.cc	(revision 120946)
+++ gnu/classpath/jdwp/natVMVirtualMachine.cc	(working copy)
@@ -62,7 +62,7 @@
 }
 
 void
-gnu::classpath::jdwp::VMVirtualMachine ::suspendThread (Thread *thread)
+gnu::classpath::jdwp::VMVirtualMachine::suspendThread (Thread *thread)
 {
   jint value;
   Integer *count;
@@ -213,7 +213,7 @@
 
     case EventRequest::EVENT_VM_INIT:
       break;
-      
+
     case EventRequest::EVENT_VM_DEATH:
       break;
     }
@@ -244,7 +244,7 @@
 
     case EventRequest::EVENT_THREAD_END:
       break;
-	
+
     case EventRequest::EVENT_CLASS_PREPARE:
       break;
 
@@ -268,14 +268,14 @@
 
     case EventRequest::EVENT_VM_INIT:
       break;
-      
+
     case EventRequest::EVENT_VM_DEATH:
       break;
     }
 }
 
 void
-gnu::classpath::jdwp::VMVirtualMachine::clearEvents (jbyte kind)
+gnu::classpath::jdwp::VMVirtualMachine::clearEvents (MAYBE_UNUSED jbyte kind)
 {
 }
 
@@ -292,69 +292,75 @@
 }
 
 jint
-gnu::classpath::jdwp::VMVirtualMachine::getClassStatus (jclass klass)
+gnu::classpath::jdwp::VMVirtualMachine::
+getClassStatus (MAYBE_UNUSED jclass klass)
 {
   return 0;
 }
 
 JArray<gnu::classpath::jdwp::VMMethod *> *
-gnu::classpath::jdwp::VMVirtualMachine::getAllClassMethods (jclass klass)
+gnu::classpath::jdwp::VMVirtualMachine::
+getAllClassMethods (MAYBE_UNUSED jclass klass)
 {
   return NULL;
 }
 
 gnu::classpath::jdwp::VMMethod *
-gnu::classpath::jdwp::VMVirtualMachine::getClassMethod (jclass klass, jlong id)
+gnu::classpath::jdwp::VMVirtualMachine::
+getClassMethod (MAYBE_UNUSED jclass klass, MAYBE_UNUSED jlong id)
 {
   return NULL;
 }
 
 java::util::ArrayList *
-gnu::classpath::jdwp::VMVirtualMachine::getFrames (Thread *thread,
-						   jint start,
-						   jint length)
+gnu::classpath::jdwp::VMVirtualMachine::getFrames (MAYBE_UNUSED Thread *thread,
+						   MAYBE_UNUSED jint start,
+						   MAYBE_UNUSED jint length)
 {
   return NULL;
 }
 
 gnu::classpath::jdwp::VMFrame *
-gnu::classpath::jdwp::VMVirtualMachine::getFrame (Thread *thread,
-						  ::java::nio::ByteBuffer *bb)
+gnu::classpath::jdwp::VMVirtualMachine::
+getFrame (MAYBE_UNUSED Thread *thread, MAYBE_UNUSED::java::nio::ByteBuffer *bb)
 {
   return NULL;
 }
 
 jint
-gnu::classpath::jdwp::VMVirtualMachine::getFrameCount (Thread *thread)
+gnu::classpath::jdwp::VMVirtualMachine::
+getFrameCount (MAYBE_UNUSED Thread *thread)
 {
   return 0;
 }
 
 jint
-gnu::classpath::jdwp::VMVirtualMachine::getThreadStatus (Thread *thread)
+gnu::classpath::jdwp::VMVirtualMachine::
+getThreadStatus (MAYBE_UNUSED Thread *thread)
 {
   return 0;
 }
 
 java::util::ArrayList *
-gnu::classpath::jdwp::VMVirtualMachine::getLoadRequests (ClassLoader *cl)
+gnu::classpath::jdwp::VMVirtualMachine::
+getLoadRequests (MAYBE_UNUSED ClassLoader *cl)
 {
   return NULL;
 }
 
 MethodResult *
-gnu::classpath::jdwp::VMVirtualMachine::executeMethod (jobject obj,
-						       Thread *thread,
-						       jclass clazz,
-						       reflect::Method *method,
-						       jobjectArray values,
-						       jboolean nonVirtual)
+gnu::classpath::jdwp::VMVirtualMachine::
+executeMethod (MAYBE_UNUSED jobject obj, MAYBE_UNUSED Thread *thread,
+	       MAYBE_UNUSED jclass clazz, MAYBE_UNUSED reflect::Method *method,
+	       MAYBE_UNUSED jobjectArray values,
+	       MAYBE_UNUSED jboolean nonVirtual)
 {
   return NULL;
 }
 
 jstring
-gnu::classpath::jdwp::VMVirtualMachine::getSourceFile (jclass clazz)
+gnu::classpath::jdwp::VMVirtualMachine::
+getSourceFile (MAYBE_UNUSED jclass clazz)
 {
   return NULL;
 }

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:

>> Please guys, remember the JNICALLs! They're not necessary for Linux
>> but at least minGW needs them...

Keith> Ugh, you know, and I really WAS being careful about that... I
Keith> double-checked that all my functions did that -- all the JVMTI ones,
Keith> at least. Sigh.

Yeah, it can be hard to remember this when developing on Linux.

Yesterday I was wondering whether there is some way we could define
JNICALL on Linux so that we would catch this error, say some harmless
attribute.  But, that is probably a bad idea since JNICALL is public.

Another idea would be to use a token-pasting "DEFUN" macro and let it
do the work:

    #define DEFUN(blahblah)  static jvmtiError JNICALL \
        _Jv_JVMTI_ ## Name blahblah
    ...
    DEFUN(SuspendThread, (...)) { ... }

But of course this is still susceptible to the problem if you forget
to use the macro.

Tom

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Tom Tromey]

>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:

Keith> Any suggestions on how to clean these long lines up better or is this
Keith> sufficient?

I think this is sufficient.
It is also ok if the occasional line goes over 80 chars.

Tom

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Keith Seitz]

Tom Tromey wrote:
>>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:
> 
> Keith> Any suggestions on how to clean these long lines up better or is this
> Keith> sufficient?
> 
> I think this is sufficient.
> It is also ok if the occasional line goes over 80 chars.

Okay, I've committed this patch. I see that natVMFrame.cc is also 
suffers from a similar problem. I will post and commit a separate patch 
for that.

Keith

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Marco Trudel]

Tom Tromey wrote:
>>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:
> 
>>> Please guys, remember the JNICALLs! They're not necessary for Linux
>>> but at least minGW needs them...
> 
> Keith> Ugh, you know, and I really WAS being careful about that... I
> Keith> double-checked that all my functions did that -- all the JVMTI ones,
> Keith> at least. Sigh.
> 
> Yeah, it can be hard to remember this when developing on Linux.
> 
> Yesterday I was wondering whether there is some way we could define
> JNICALL on Linux so that we would catch this error, say some harmless
> attribute.  But, that is probably a bad idea since JNICALL is public.
> 
> Another idea would be to use a token-pasting "DEFUN" macro and let it
> do the work:
> 
>     #define DEFUN(blahblah)  static jvmtiError JNICALL \
>         _Jv_JVMTI_ ## Name blahblah
>     ...
>     DEFUN(SuspendThread, (...)) { ... }
> 
> But of course this is still susceptible to the problem if you forget
> to use the macro.

Please allow me to somehow broaden the topic you started...
Since I got involved with GCC/GCJ, I run into a lot of compilation 
errors. To do some unreliable mind-based statistics, I remember about 2 
or 3 GCC problems (TLS, unfixed cygwin problem, one to fake the stats). 
When it comes to GCJ, I think at least every second time I tried to 
compile after a week or two of being away, compilation was broken. This 
is maybe about 30 times but more likely way more.
Don't get me wrong, I'm not here to blame anyone. I'm very happy all you 
guys are developing so hard on gcj. I just wonder how the GCC staff are 
able to keep the quality so constant and gcj... well... unfortunately 
not that constant. Can we do something to change that?

Interested for feedback...
Marco

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[David Daney]

Marco Trudel wrote:
> Tom Tromey wrote:
>>>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:
>>
>>>> Please guys, remember the JNICALLs! They're not necessary for Linux
>>>> but at least minGW needs them...
>>
>> Keith> Ugh, you know, and I really WAS being careful about that... I
>> Keith> double-checked that all my functions did that -- all the JVMTI 
>> ones,
>> Keith> at least. Sigh.
>>
>> Yeah, it can be hard to remember this when developing on Linux.
>>
>> Yesterday I was wondering whether there is some way we could define
>> JNICALL on Linux so that we would catch this error, say some harmless
>> attribute.  But, that is probably a bad idea since JNICALL is public.
>>
>> Another idea would be to use a token-pasting "DEFUN" macro and let it
>> do the work:
>>
>>     #define DEFUN(blahblah)  static jvmtiError JNICALL \
>>         _Jv_JVMTI_ ## Name blahblah
>>     ...
>>     DEFUN(SuspendThread, (...)) { ... }
>>
>> But of course this is still susceptible to the problem if you forget
>> to use the macro.
> 
> Please allow me to somehow broaden the topic you started...
> Since I got involved with GCC/GCJ, I run into a lot of compilation 
> errors. To do some unreliable mind-based statistics, I remember about 2 
> or 3 GCC problems (TLS, unfixed cygwin problem, one to fake the stats). 
> When it comes to GCJ, I think at least every second time I tried to 
> compile after a week or two of being away, compilation was broken. This 
> is maybe about 30 times but more likely way more.
> Don't get me wrong, I'm not here to blame anyone. I'm very happy all you 
> guys are developing so hard on gcj. I just wonder how the GCC staff are 
> able to keep the quality so constant and gcj... well... unfortunately 
> not that constant. Can we do something to change that?
> 
> Interested for feedback...

You are kind of comparing apples to oranges.  Most of the changes in the 
GCC core have to do with code generation.  And as such don't usually 
effect the interaction between the OS and the language runtime.

Many of the changes in libgcj have to do with the interaction of the 
runtime with the OS.  There is potential for breakage here much more 
often.  The fact that most of the developers are working under Linux 
means that the changes don't get tested against mingw.  I appreciate the 
fact that you are fixing things, but I don't think you can expect much 
testing on mingw to be done by others.  So the situation is likely to 
continue.

I guess I have not real suggestion about how to improve things, only 
excuses as to why they are as they are.

David Daney

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Marco Trudel]

I sent this to the patches list as well. I assume Keith just hit the 
wrong button in the mail application:

Keith Seitz wrote:
> Marco Trudel wrote:
> 
>>> Keith> Ugh, you know, and I really WAS being careful about that... I
>>> Keith> double-checked that all my functions did that -- all the JVMTI 
>>> ones,
>>> Keith> at least. Sigh.
> 
> And starting today, I'm turning a new leaf. Before I commit any patch, I 
> will verify that it builds with a linux-mingw32 cross compiler. [Okay, 
> actually, starting later today when it "finishes" building.]

I don't know if thats a good solution. I'm sure you can use your time 
better than that. What about a regularly cross-compilation session where 
error reports are sent to the list and the responsible guys try to fix 
problems? No, not that a good idea I guess...


Marco

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Marco Trudel]

David Daney wrote:
> Marco Trudel wrote:
>> Tom Tromey wrote:
>>>>>>>> "Keith" == Keith Seitz <keiths@redhat.com> writes:
>>>
>>>>> Please guys, remember the JNICALLs! They're not necessary for Linux
>>>>> but at least minGW needs them...
>>>
>>> Keith> Ugh, you know, and I really WAS being careful about that... I
>>> Keith> double-checked that all my functions did that -- all the JVMTI 
>>> ones,
>>> Keith> at least. Sigh.
>>>
>>> Yeah, it can be hard to remember this when developing on Linux.
>>>
>>> Yesterday I was wondering whether there is some way we could define
>>> JNICALL on Linux so that we would catch this error, say some harmless
>>> attribute.  But, that is probably a bad idea since JNICALL is public.
>>>
>>> Another idea would be to use a token-pasting "DEFUN" macro and let it
>>> do the work:
>>>
>>>     #define DEFUN(blahblah)  static jvmtiError JNICALL \
>>>         _Jv_JVMTI_ ## Name blahblah
>>>     ...
>>>     DEFUN(SuspendThread, (...)) { ... }
>>>
>>> But of course this is still susceptible to the problem if you forget
>>> to use the macro.
>>
>> Please allow me to somehow broaden the topic you started...
>> Since I got involved with GCC/GCJ, I run into a lot of compilation 
>> errors. To do some unreliable mind-based statistics, I remember about 
>> 2 or 3 GCC problems (TLS, unfixed cygwin problem, one to fake the 
>> stats). When it comes to GCJ, I think at least every second time I 
>> tried to compile after a week or two of being away, compilation was 
>> broken. This is maybe about 30 times but more likely way more.
>> Don't get me wrong, I'm not here to blame anyone. I'm very happy all 
>> you guys are developing so hard on gcj. I just wonder how the GCC 
>> staff are able to keep the quality so constant and gcj... well... 
>> unfortunately not that constant. Can we do something to change that?
>>
>> Interested for feedback...
> 
> You are kind of comparing apples to oranges.  Most of the changes in the 
> GCC core have to do with code generation.  And as such don't usually 
> effect the interaction between the OS and the language runtime.
> 
> Many of the changes in libgcj have to do with the interaction of the 
> runtime with the OS.  There is potential for breakage here much more 
> often.

Good point!


> The fact that most of the developers are working under Linux 
> means that the changes don't get tested against mingw.  I appreciate the 
> fact that you are fixing things, but I don't think you can expect much 
> testing on mingw to be done by others.  So the situation is likely to 
> continue.

Don't get me wrong, I'm not only talking about mingw. I'm talking about 
compiling in general. But I think the main problem really is 
cross-compiling as you imply. For instance, the current trunk is broken 
for all cross-compilations where build != host and where build can't run 
binaries from host :-(


> I guess I have not real suggestion about how to improve things, only 
> excuses as to why they are as they are.

That's ok. You're pushing the discussion, thats good :-) But I think 
you're right. We're probably keeping the situation. After all, it's not 
that bad...


Marco

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[David Daney]

Marco Trudel wrote:
> Don't get me wrong, I'm not only talking about mingw. I'm talking about 
> compiling in general. But I think the main problem really is 
> cross-compiling as you imply. For instance, the current trunk is broken 
> for all cross-compilations where build != host and where build can't run 
> binaries from host :-(
> 
I used to do many more mipsel-linux cross compiles, but have lately 
taken to doing native builds on that target.

Perhaps I should start doing more cross builds.  I will put it on my 
to-do list.

David Daney

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Tom Tromey]

>>>>> "Marco" == Marco Trudel <mtrudel@gmx.ch> writes:

Marco> I just wonder how the GCC
Marco> staff are able to keep the quality so constant and
Marco> gcj... well... unfortunately not that constant.

You're doing probably the hardest build there is: a Canadian cross
targeting Windows.  The core gcj developers generally are doing native
builds, and not many gcj developers use Windows; also the ones who do
use Windows tend to be less active.  Finally, we're in a time where
gcj is changing rapidly, which makes the ordinary background problem
worse.

That's the explanation for how it is... but:

Marco> Can we do something to change that?

Yes, I think so.  One thing we could do is set up an automated tester
on the GCC compile farm (http://gcc.gnu.org/wiki/CompileFarm) that
does a build like yours.  That way breakage would be noticed more quickly.

Would you be able to set something up?  I may be able to help a bit;
we could take some infrastructure stuff from the Classpath builder.

Tom

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Marco Trudel]

Tom Tromey wrote:
>>>>>> "Marco" == Marco Trudel <mtrudel@gmx.ch> writes:
> 
> Marco> I just wonder how the GCC
> Marco> staff are able to keep the quality so constant and
> Marco> gcj... well... unfortunately not that constant.
> 
> You're doing probably the hardest build there is: a Canadian cross
> targeting Windows.  The core gcj developers generally are doing native
> builds, and not many gcj developers use Windows; also the ones who do
> use Windows tend to be less active.  Finally, we're in a time where
> gcj is changing rapidly, which makes the ordinary background problem
> worse.

Yes. Andrew also said it quite adequate:
	We're in "rapid development" mode at the moment.
In my opinion, progress is more worthy than stability and I'm glad GCJ 
is being worked so hard on.


> That's the explanation for how it is... but:
> 
> Marco> Can we do something to change that?
> 
> Yes, I think so.  One thing we could do is set up an automated tester
> on the GCC compile farm (http://gcc.gnu.org/wiki/CompileFarm) that
> does a build like yours.  That way breakage would be noticed more quickly.
> 
> Would you be able to set something up?  I may be able to help a bit;
> we could take some infrastructure stuff from the Classpath builder.

Very interesting. I was thinking about something like that for a long 
time but didn't knew that there is already infrastructure around. I 
would suggest to:
- regularly try to compile a host=Linux target=mingw and host=mingw 
target=mingw compiler. Now what is regularly? What makes sense? Every 
day? Every second day? Once a week?
- If it failes: email notification. To who? Me? GCJ list?

I'd be interested in setting up a mingw-testing account and maintaining 
it. This could really help keeping things working.


Thanks for the Idea
Marco

Re: [RFA] Add JDWP VM_INIT JVMTI callback

[Tom Tromey]

>>>>> "Marco" == Marco Trudel <mtrudel@gmx.ch> writes:

>> Yes, I think so.  One thing we could do is set up an automated tester
>> on the GCC compile farm (http://gcc.gnu.org/wiki/CompileFarm) that
>> does a build like yours.

Marco> - regularly try to compile a host=Linux target=mingw and host=mingw
Marco> target=mingw compiler. Now what is regularly? What makes sense? Every
Marco> day? Every second day? Once a week?

For the Classpath builder (http://builder.classpath.org) we simply do
continuous build cycles.  I think there's a 30 minute delay, or
something short like that, between the end of one build and the start
of the next.

Marco> - If it failes: email notification. To who? Me? GCJ list?

We could set up a new list, or re-use an existing one -- perhaps the
Classpath build list.  Geoff's old tester used to just send email to
anyone who might have broken the build, those scripts might be in
gcc/contrib.

For Classpath we also have an irc bot that you can query to get the
status.  This sort of thing is surprisingly easy to set up.  We could
for instance have a bot that says something when a build fails.

Tom