Re: [RFA] Add JDWP VM_INIT JVMTI callback

[David Daney <ddaney at avtrex dot com>]

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