From: Godmar Back (gback@cs.utah.edu)
Date: Thu Jan 07 1999 - 04:37:42 EST
I had thought of that too.
I would also attack the problem of large jvalue arrays in callMethodA/V
which increases floating garbage, let alone the fact that knowing the
length in advance will allow us to use alloca --- quite unlike the
current unchecked array.
However, I think Peter means something else here:
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?
Preparsing would only benefit users of callMethodA, such as the interpreter
or Method.invoke. Nevertheless, it may be a good idea. It would also
allow us to drop the utf8, compressing symbol space even further.
About the static/dynamic issue: what will be the lookup rule if a name
is both hard-coded and can be found dynamically? Should the dll
override the static function or the other way around?
Also, are there going to be knobs to say which lib you want to link
statically?
- Godmar
>
> On Jan 4, 1999, peter@transvirtual.com wrote:
>
> > (1) improve JNI call speed
>
> A long time ago, I had suggested to Tim and Godmar that we could
> pre-parse signatures of methods and store this pre-parsed data in some
> form that eases invocation of native methods and invocations of Java
> methods from them.
>
> I'm only sending this message about it so that I can mark it and not
> forget about it again :-)
>
> --
> Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
> oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
> Universidade Estadual de Campinas, SP, Brasil
>
>
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:31 EDT