performance problems with classpath 0.09 on Jikes RVM
I'm doing some initial performance comparisons of classpath 0.08 and classpath 0.09 on Jikes RVM (cvs head). I've found that the performance of _228_jack (one of the SPECjvm98 benchmarks) suffers a serve degradation on classpath 0.09. It is twice as slow (10 seconds vs 5 seconds on my machine with a production version of Jikes RVM cvs head) with the only difference being the version of classpath. An initial investigation seems to point the finger at the changes in the classpath I/O layers between these two versions. In particular, the profiling data suggests a large increase in both direct and indirect costs of I/O due to the implementation of gnu_java_nio_channels_FileChannelImpl.get_native_fd which is doing 3 JNI calls per invocation, two of which are going to convert strings from C = Java causing allocation in the VM and driving up the GC rate (time spent in GC doubles looking at classpath 0.08 vs. classpath 0.09). I think there is a relatively easy fix to this particular problem by computing and caching the fieldId as part of the init method. I'm willing to play with this and provide a patch if this does ease the performance degradation. But I did want to check to see if (1) anyone else has noted the problem and (2) if a fix is already being prepared. thanks, --dave___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: performance problems with classpath 0.09 on Jikes RVM
Here's some more data: dynamic count of JNI functions executed in 1 iteration of jack size 100 on classpath 0.08 and classpath 0.09 with Jikes RVM. Note the massive number of calls from FileChannelImpl.get_native_fd 2/3 of which are unnecessary. Unless I hear that someone else has already fixed it, I'll put a patch together in the next couple of days. --dave [EMAIL PROTECTED] SPECjvm98]$ cat jack.trace.0.08 | grep JNI | sort | uniq -c | sort -nr 10017 JNI called: GetByteArrayElements 10017 JNI called: ReleaseByteArrayElements 408 JNI called: ReleaseStringUTFChars 408 JNI called: GetStringUTFChars 6 JNI CallXXXMethod: (mid 7653) java.lang.Double.isNaN 6 JNI called: NewStringUTF 6 JNI called: CallStaticBooleanMethod 5 JNI called: GetStaticFieldID 3 JNI called: SetLongField 3 JNI called: GetStaticObjectField 3 JNI called: ExceptionOccurred 2 JNI called: GetStaticDoubleField 1 JNI called: GetStaticMethodID 1 JNI called: GetFieldID [EMAIL PROTECTED] SPECjvm98]$ cat jack.trace.0.09 | grep JNI | sort | uniq -c | sort -nr 301590 JNI called: GetIntField 301590 JNI called: GetFieldID 301590 JNI called: FindClass 10388 JNI called: GetByteArrayElements 10388 JNI called: ReleaseByteArrayElements 408 JNI called: ReleaseStringUTFChars 408 JNI called: GetStringUTFChars 6 JNI CallXXXMethod: (mid 5333) java.lang.Double.isNaN 6 JNI called: NewStringUTF 6 JNI called: CallStaticBooleanMethod 5 JNI called: GetStaticFieldID 3 JNI called: SetStaticObjectField 3 JNI called: NewObject 3 JNI called: ExceptionOccurred 2 JNI called: GetStaticDoubleField 1 JNI called: GetStaticMethodID 1 JNI called: GetMethodID___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: performance problems with classpath 0.09 on Jikes RVM
On Fri, 2004-05-07 at 14:21, David P Grove wrote: Here's some more data: dynamic count of JNI functions executed in 1 iteration of jack size 100 on classpath 0.08 and classpath 0.09 with Jikes RVM. Note the massive number of calls from FileChannelImpl.get_native_fd 2/3 of which are unnecessary. Unless I hear that someone else has already fixed it, I'll put a patch together in the next couple of days. Yes please do. I think it's part of the hacking guide, but fieldID and methodID lookups are supposed to be cached where possible. Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: performance problems with classpath 0.09 on Jikes RVM
Here's a patch. Works with Jikes
RVM and reduces our classpath 0.09 performance degradation on _228_jack
to a slightly more tolerable 5%. Eliot's point is probably a good
one though, this is an unfortunate place to be having to cross JNI boundaries.
Probably the right long term solution for Jikes RVM is to provide
our own all Java version of FileChannelImpl that avoids exposing
us to the remaining performance problems. This would also let us
hook into the nonblocking I/O layer in Jikes RVM if we wanted to.
--dave
Index: gnu_java_nio_channels_FileChannelImpl.c
===
RCS file: /cvsroot/classpath/classpath/native/jni/java-nio/gnu_java_nio_channels_FileChannelImpl.c,v
retrieving revision 1.10
diff -u -r1.10 gnu_java_nio_channels_FileChannelImpl.c
--- gnu_java_nio_channels_FileChannelImpl.c1
May 2004 10:40:56 -1.10
+++ gnu_java_nio_channels_FileChannelImpl.c8
May 2004 02:01:20 -
@@ -87,11 +87,27 @@
#define CONVERT_SSIZE_T_TO_JINT(x) ((jint)(x 0x))
#define CONVERT_JINT_TO_SSIZE_T(x) (x)
+/* cache fieldID of gnu.java.nio.channels.FileChannelImpl.fd */
+static jfieldID native_fd_fieldID;
+
static jint get_native_fd(JNIEnv *env, jobject obj)
{
+ return (*env)-GetIntField (env, obj, native_fd_fieldID);
+}
+
+/*
+ * Library initialization routine. Called as part of java.io.FileDescriptor
+ * static initialization.
+ */
+JNIEXPORT void JNICALL
+Java_gnu_java_nio_channels_FileChannelImpl_init (JNIEnv *env, jclass clazz)
+{
jclass clazz_fc;
- jfieldID field_fd;
+ jfieldID field;
+ jmethodID constructor;
+ jobject obj;
+ /* Initialize native_fd_fieldID so we only compute it once! */
clazz_fc = (*env)-FindClass (env, gnu/java/nio/channels/FileChannelImpl);
if (!clazz_fc)
{
@@ -99,26 +115,14 @@
return -1;
}
- field_fd = (*env)-GetFieldID (env, clazz_fc, fd,
I);
- if (!field_fd)
+ field = (*env)-GetFieldID (env, clazz_fc, fd, I);
+ if (!field)
{
JCL_ThrowException(env, IO_EXCEPTION, Internal
error);
return -1;
- }
-
- return (*env)-GetIntField (env, obj, field_fd);
-}
+ }
-/*
- * Library initialization routine. Called as part of java.io.FileDescriptor
- * static initialization.
- */
-JNIEXPORT void JNICALL
-Java_gnu_java_nio_channels_FileChannelImpl_init (JNIEnv *env, jclass clazz)
-{
- jfieldID field;
- jmethodID constructor;
- jobject obj;
+ native_fd_fieldID = field;
constructor = (*env)-GetMethodID (env, clazz, init,
(II)V);
if (! constructor)___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
