On 4/30/08, John Rose <[EMAIL PROTECTED]> wrote:
>
> On Apr 30, 2008, at 12:48 PM, John Wilson wrote:
>
>
> This removes the need for boxing/unboxing and really should not lead
>
> to an excessive number of interfaces being generated.
> That schema of interfaces is about the same as is being proposed for java
> closures by Neal Gafter.
>
> It's not too many for the JVM, though there are too many of them to know by
> name, hence Neal's function type syntax. The compromise with object types
> (which are quantified as generic type variables) leads to inserted casts.
> The casts can sometimes be a performance hit (hence the JVM's use of
> strongly typed reference arguments).
>
> Underneath the N interfaces there are M (M>N) classes, one for each target
> method. With method handles, for M target methods, you have M little
> objects, not M classes. M classes is excessive, whether or not you control
> the number N of call-signature interfaces.
>
> More thoughts on reflect.Method:
>
> There's a compatibility problem with making reflect.Method polymorphic: It
> is final. There are ways to fudge that, such as making the constructor
> JVM-private.
>
> There's a performance problem with making reflect.Method the direct receiver
> of an invoke, since Method is a very rich class; they are probably 10x
> larger than a minimal method handle. The effort of constructing one (even
> if you make some stuff lazy) goes far beyond the intrinsic cost of naming a
> method.
>
> But reflect.Method could contain a function type object ("closure"):
>
>
> {PrintStream,int,int=>void} caller = mymethod.getCaller();
> caller.invoke(System.out, 0, 30);
>
> And, in turn, the closure could use method handles under the cover to
> provide direct access, without the need for M classes. There would be N
> closure-to-method-handle implementations. Each implementation would invoke
> an underlying method handle with the right signature.
>
> Or (I don't know if it could be made to work, but it's worth thinking about)
> method handles could interoperate more tightly with closures, by having each
> individual method handle somehow take on the appropriate function interface
> type.
I have done some work on optimising method calls when you are able to
control the bytecode generated for the target (in this case Ng code
calling Ng classes). I have documented it here
http://docs.google.com/Doc?id=ah76zbd6xsx2_9ck33c8dp if you are
interested.
It seems to work well and is a lot faster than using reflection and it
solves the problem of making super.foo() calls via the MetaClass.
So I'm only really looking at reflection to dispatch calls to Java
methods. I have a scheme for doing a similar sort of method dispatch
for Java classes but it requires run time bytecode generation and a
new class for every Java class.
John Wilson
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
