[armedbear-devel] Question about calling Java

[Alessio Stalla]

On Thu, Feb 4, 2010 at 4:34 PM, dmiles at users.sourceforge.net
<logicmoo at gmail.com> wrote:
>
>
> On Thu, Feb 4, 2010 at 7:19 AM, Alessio Stalla <alessiostalla at gmail.com>
> wrote:
>>
>> On Thu, Feb 4, 2010 at 3:49 PM, Ville Voutilainen
>> <ville.voutilainen at gmail.com> wrote:
>> > On 4 February 2010 16:39, Axel Rauschmayer <axel at rauschma.de> wrote:
>> >> Quick comment: The latest incarnation of the Java FFI API allows one to
>> >> use strings whenever a class object or a method object is required:
>> >> (jnew "my.package.MyClass" arg) for new my.package.MyClass(arg)
>> >> (jcall "methodName" obj arg) for obj.methodName(arg)
>> >
>> > Does it allow both the "old" way and the stringified way?
>>
>> Yes, it does. The stringified way is obviously slower, because it
>> looks up the method at runtime.
>
> So you are saying in the current interpreted mode it has to resolve the
> stringified method each time?
>
> So it would be fastest to:
>
>   (setq *myjmethod* (jmethod "mypackage.AndClass" "methodName" (jclass
> "argType1") ))
>
>  Then use (jcall *myjmethod* obj arg).  Is the most effecient?
>
>   instead of
>
>    (jcall (jmethod "mypackage.AndClass" "methodName" (jclass "argType1") )
> obj arg)

No, those two are equally efficient because the compiler caches the
method automatically in the second case.

What is slower is (jcall "methodName" obj arg) i.e. without a jmethod
form. methodName will need to be resolved for every call, so it's not
a wise choice in code where performance is important. OTOH, the
string-based solution is more flexible; it works for any obj and arg
provided that obj has a method "methodName" with a single parameter,
whose type is compatible with the type of arg.

> In the future, (JLinker says in their future to so no hurry)  that these
> forms will eventualy be bytecode.

(jcall (jmethod ...) ...) could definitely be translated to
invokevirtual bytecode when all the arguments to jmethod are known at
compile time. Same for (jnew (jconstructor ...) ...).

> And ABCL will probably beat Allegro to it!
>  Since we can use Hickey's methodolgy he used in clojure for finality of the
> bytecode methods.

Afaik, declaring methods to be final has little impact on performance
with recent JVMs. HotSpot is able to infer if a method can or not be
overridden and perform the appropriate optimizations. If later on a
class is dynamically loaded that overrides an optimized method,
HotSpot will "unoptimize" it.

Alessio

> That the methods themselves wont ever need to use a java.lang.Method.invoke
> anymore unless the user left it too ambiguous.