On 4/30/08, John Rose <[EMAIL PROTECTED]> wrote:
[snip]
>
> Whist Method Handles are quite interesting I'd rather see effort being
> expended in making java.lang.reflect.Method faster and more useful (we
> discussed allowing downcasting to types which avoided the meed to box
> the parameters, and unbox the result at one point on this list). If
> only on the basis that this could be in the next version of the JVM as
> an incremental improvement to refection rather than as a change to
> support "dynamic languages".
> Those discussions contributed integrally to the method handle design; thank
> you. MethodHandle is the downcast type that supports the direct, unboxed
> call.
>
> The present unboxed alternative (many interfaces + many classes) scales
> poorly; see Gilad's slide #20 in:
>
> http://blogs.sun.com/roller/resources/gbracha/JAOO2005.pdf
>
> Even if such an interface/class pair were optimized down to 100 words it
> would still be 10x more expensive in space than a method handle, and no
> faster in call sequence, than a method handle. (Data point: Pack200
> shrinks a one-method anonymous adapter class to about 90 bytes. That's a
> robust lower bound; the JVM has to expand it before it's usable.) Space
> still matters these days, because a computer runs in its cache.
>
> Method handles will make reflection faster, and also less necessary.
> Implementors will take their pick between compatibility and bleeding edge
> optimization, or take both with a switch setting at startup
.
Perhaps I was being naive about how downcasting of Method would be done:
It's obviously possible to construct a naming scheme for interfaces
which allow you to determine the method signature of the single method
it contains from its name. For the purposes of this we only need to
have method signatures with primitive types and Object.
The system classloader can dynamically generate these interfaces on demand.
The number of different flavours of interface required in any one
program would be reasonably modest and, I would imagine, would grow
less fast than the size of the program.
So, choosing a not very practical way of encoding the name of the
interface, I could call write(char[], int, int) on a Writer by
generation the following code:
(("void foo (Object, int, int)")mymethod).invoke(myWriterInstance,
myCharArray, 0, 30)
Where "void foo (Object, int, int)" would be the name of the
dynamically created interface for all void methods which took and
Object and two ints.
This removes the need for boxing/unboxing and really should not lead
to an excessive number of interfaces being generated.
Am I overlooking something?
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
-~----------~----~----~----~------~----~------~--~---
