On Thu, Feb 4, 2010 at 4:34 PM, dmiles@users.sourceforge.net logicmoo@gmail.com wrote:
On Thu, Feb 4, 2010 at 7:19 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Thu, Feb 4, 2010 at 3:49 PM, Ville Voutilainen ville.voutilainen@gmail.com wrote:
On 4 February 2010 16:39, Axel Rauschmayer axel@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.