Re: Minor bug, JVMPI observation

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Boehm, Hans wrote:

>I just discovered the following bug, which I previously introduced into
>natString.cc.  This is completely broken if JVMPI is disabled.  This
>strongly suggests that everyone is building with JVMPI enabled (i.e. without
>--disable-jvmpi), whether they know it or not.  Is this intentional?  (I
>don't think it makes a large difference, yet.  I expect that to change
>if/when we get direct calls GC_gcj_malloc.)
>
>OK to commit to the trunk?
>

Yeah, I think jvmpi should be disabled by default, anyone disagree?

>Index: java/lang/natString.cc
>===================================================================
>RCS file: /cvs/gcc/gcc/libjava/java/lang/natString.cc,v
>retrieving revision 1.24
>diff -u -r1.24 natString.cc
>--- natString.cc	2001/07/30 20:24:17	1.24
>+++ natString.cc	2001/11/13 21:36:15
>@@ -400,7 +400,7 @@
> #else
>   // Class needs no initialization, and there is no finalizer, so
>   // we can go directly to the collector's allocator interface.
>-  jstring obj = (jstring) _Jv_AllocPtrFreeObj(&StringClass, sz);
>+  jstring obj = (jstring) _Jv_AllocPtrFreeObj(sz, &StringClass);
> #endif
>

Is the #ifdef JVMPI here really neccessary? Since _Jv_AllocPtrFreeObj is 
inline, the only thing is saves is the _Jv_InitClass, which is also 
inline and, I think, very cheap considering it is __builtin_expect'ed 
and the class object needs to be dereferenced soon anyway in order to 
set the new object's vtable.

regards

Bryce.