Re: Curious Kaffe vs. jdk speed test results under Linux

Date view Thread view Subject view Author view

From: Godmar Back (gback@cs.utah.edu)
Date: Thu Jan 07 1999 - 05:00:05 EST


>
> On Jan 7, 1999, Godmar Back <gback@cs.utah.edu> wrote:
>
> > I think he means the speed with which a jit compiled function calls
> > a JNI function. This does not depend on the signature being pre-parsed,
> > it simply depends on the quality of the code emitted in Kaffe_JNI_Wrapper.
> > Or am I missing something here?
>
> I think Kaffe_JNI_Wrapper is fast enough already, the problem is the
> other way round: JNI invocations (i.e., from native to Java) are slow,
> because the signature must be parsed and the arguments must be
> converted to whatever format the Java code expects according to this
> signature.

I know that; that's what I meant by "users of callMethodA/V" in the
paragraph following this one. But what I'm wondering is is whether this
really is a bottleneck in the AWT?
Doing a grep 'Call' on evt.c gives:

void jthreadedBlockEAGAIN(int fd); /* move to SysCallInterface ? */
return (*env)->CallStaticObjectMethod( env, KeyEvent, getKeyEvent,
return (*env)->CallStaticObjectMethod( env, MouseEvent, getMouseEvent,
return (*env)->CallStaticObjectMethod( env, MouseEvent, getMouseEvent,
return (*env)->CallStaticObjectMethod( env, MouseEvent, getMouseEvent,
return (*env)->CallStaticObjectMethod( env, FocusEvent, getFocusEvent, X->srcIdx, X->evtId);
return (*env)->CallStaticObjectMethod( env, PaintEvent, getPaintEvent,
return (*env)->CallStaticObjectMethod( env, WindowEvent, getWindowEvent,
return (*env)->CallStaticObjectMethod( env, WindowEvent, getWindowEvent,
return (*env)->CallStaticObjectMethod( env, ComponentEvent, getComponentEvent,
return (*env)->CallStaticObjectMethod( env, WindowEvent, getWindowEvent,

Naively I don't see how cutting off a few microseconds here
would help us in any significant way other than getting more CaffeineMarks---
user interfaces are called that cause they have a user in the loop.

But, img.c also has 5 calls in it, and those probably do some
performance-critical image processing or something.

I'm all for doing the pre-parsing --- be it for principal reasons
(stupidly doing something over and over and not even saving memory
in exchange, but wasting some!)

>
> > About the static/dynamic issue: what will be the lookup rule if a name
> > is both hard-coded and can be found dynamically?
>
> It depends on the order in which libraries were loaded. libltdl (the
> libtool library that implements portable dlopening) will dlsym from a
> single library at a time, so I have created a loop that tries a dlsym
> for one library at a time, until it is found or no more libraries are
> available.
>
> However, if more than one library is statically linked, it is possible
> that a symbol from the second library will be found in the dlsym of
> the first one. libtool may modify this in the future, but this is
> current state of libltdl.

>From that I conclude that there won't be a static table mapping
symbol names and values anymore and no more sed scripts to extract them?
Really, it'd be nice to have a FAQ about how it all works.
What about architectures that don't have a libltdl port?

        - Godmar


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:31 EDT