Method handles seem like a great way of speeding up reflection - which
would be great - so don't get me wrong in the text below I am not
against their introduction. Below I am musing on using them for inner
classes/closures.
To use a method handle for an inner class/closure would require
certain, not necessarily desirable, semantics for the inner class/
closure. To give an example I need some syntax because Java currently
does not have any suitable syntax, I have chosen some syntax not
particularly aligned with any inner class/closure proposal to
illustrate my thoughts, because I don't want any semantic baggage from
existing proposals. If the keyword 'shared' denoted a local variable
that had a lifetime beyond the enclosing method call and allowed write
access and if the keyword 'method' introduced a local method inside
another method then:
class Foo {
int bar( int[] is ) {
shared int sum = 0;
method void summer( int x ) { sum += x; }
for ( int i : is ) { summer( i ); }
return sum;
}
}
Then the compiler could translate this into:
class Foo {
private int bar$sum; // shared
private final void bar$summer( int x ) { bar$sum += x; } // inner
method
private final MethodHandle bar$summer$MH =
insertArgument( findVirtual( Foo.class, "bar$summer", ...), this ); //
create a handle to the method
int bar( int[] is ) {
sum = 0;
for ( int i : is ) { bar$summer$MH.invoke( i ); }
return bar$sum;
}
}
There are two things to note:
1. The method handle isn't needed in this example since you could call
bar$summer directly. However for something executed later, e.g. an
event, the handle is needed.
2. The code isn't thread safe and therefore not suitable for
invocation later, e.g. as an event (though OK for some Swing events).
If you use a separate class then you get the thread safety (one
possible transformation below):
class Foo$bar$Sum{
int value = 0; // shared local variable
}
class Foo {
private final static void bar$summer( Foo$bar$sum sum, int x )
{ sum.value += x; } // inner method
int bar( int[] is ) {
final Foo$bar$Sum sum = new Foo$bar$Sum();
for ( int i : is ) { bar$summer( sum, i ); }
return sum.value;
}
}
The disadvantage of this separate class approach, is that class Foo$bar
$sum is unlikely to be garbage collected.
Is there a way to use method handles for inner classes/closures?
Just to reiterate I think speeding up reflection is a great idea, I am
just not sure of other uses.
On Apr 19, 4:43 am, John Rose <[EMAIL PROTECTED]> wrote:
> On Apr 18, 2008, at 3:28 AM, Rémi Forax wrote:
>
> > I tried to understand how to implement closure with method handles.
> > So correct me if i'm wrong:
> > - a method handle is a Java Object with a special header
> > let say it's a 3 words header, the last word is a pointer to
> > the signature of the method handle.
>
> That's a good model for the low-level or primitive method handles
> (MHD, MHB). A method handle invocation must first do a dynamic
> signature check (signatures are JVM-level proxies for an infinite
> schema of function-like interfaces), possibly do some argument
> wrangling, and then jump to the target method.
>
> The other kind is any object that implements the MethodHandle
> interface and supplies an invoke method that matches getType. That
> kind is not a new kind of JVM data structure, but an ordinary Java
> object. See this blog paragraph:> So, at the risk of adding a chore to the
> JVM implementor’s list, I
> > think an object of such a type should serve (uniformly in the
> > contexts described above) as a method handle. (It is may be
> > necessary to ask that R implement the marker interface and the
> > getType method; but is something the system could also figure out
> > well enough on its own.) I admit that this is not a necessary
> > feature, but it could cut in half the number of small method-like
> > objects running around in some systems.
>
> You are right about the differences between closures and method handles.
>
> > - in order to use covariance/contravariance, you need
> > to use an adapt method that create a *new* method handle
>
> That would be true if method handle signatures were identical to
> closure signatures.
>
> But method handles are JVM-level objects. To implement closures, I
> think it would be better to erase the function signatures first, then
> work with method handles on the erased signatures.
>
> > Because adapt create a new handle, closures are not method handles.
>
> ...Unless the type changes are compile-time only, or unless we are
> talking about closure conversion instead of mere subtyping.
>
> > Ok, let now say a closure is an object that contains a method
> > handle and
> > invoke is performed by using the new invokedynamic bytecode.
>
> Setting aside invokedynamic for the moment, you could factor a
> significant chunk of closures implementation into two parts. First,
> a template-generated schema of implementation classes, one per
> function interface type. The classes embody the semantics of
> closures, referring on invoke to a private method handle (as in your
> sketch). The method handle would have a signature identical to the
> erased (JVM-level) signature of the function type.
>
> Second, when a closure expression is evaluated, the compiler puts the
> code into a private method on a nearby class, and generates a method
> handle to it. (If the JVM is really accommodating, this ought to be
> an "ldc" instruction!) It then wraps the standard function-type
> around the method handle.
>
> This division is labor is in most ways better than what we get
> without method handles: The compiler must generate not just a
> private method but a whole private class, which implements a function
> type and defines an invoke method. The point of method handles (in
> this application) is to allow closure methods to be grouped naturally
> in the module that uses them, instead of spread out as 'invoke'
> methods in a bunch of inner classes.
>
> I'm sure we don't need invokedynamic (i.e., programmatically defined
> call site linkage) to implement closures, with or without method
> handles.
>
> -- John
On Apr 19, 4:43 am, John Rose <[EMAIL PROTECTED]> wrote:
> On Apr 18, 2008, at 3:28 AM, Rémi Forax wrote:
>
> > I tried to understand how to implement closure with method handles.
> > So correct me if i'm wrong:
> > - a method handle is a Java Object with a special header
> > let say it's a 3 words header, the last word is a pointer to
> > the signature of the method handle.
>
> That's a good model for the low-level or primitive method handles
> (MHD, MHB). A method handle invocation must first do a dynamic
> signature check (signatures are JVM-level proxies for an infinite
> schema of function-like interfaces), possibly do some argument
> wrangling, and then jump to the target method.
>
> The other kind is any object that implements the MethodHandle
> interface and supplies an invoke method that matches getType. That
> kind is not a new kind of JVM data structure, but an ordinary Java
> object. See this blog paragraph:> So, at the risk of adding a chore to the
> JVM implementor’s list, I
> > think an object of such a type should serve (uniformly in the
> > contexts described above) as a method handle. (It is may be
> > necessary to ask that R implement the marker interface and the
> > getType method; but is something the system could also figure out
> > well enough on its own.) I admit that this is not a necessary
> > feature, but it could cut in half the number of small method-like
> > objects running around in some systems.
>
> You are right about the differences between closures and method handles.
>
> > - in order to use covariance/contravariance, you need
> > to use an adapt method that create a *new* method handle
>
> That would be true if method handle signatures were identical to
> closure signatures.
>
> But method handles are JVM-level objects. To implement closures, I
> think it would be better to erase the function signatures first, then
> work with method handles on the erased signatures.
>
> > Because adapt create a new handle, closures are not method handles.
>
> ...Unless the type changes are compile-time only, or unless we are
> talking about closure conversion instead of mere subtyping.
>
> > Ok, let now say a closure is an object that contains a method
> > handle and
> > invoke is performed by using the new invokedynamic bytecode.
>
> Setting aside invokedynamic for the moment, you could factor a
> significant chunk of closures implementation into two parts. First,
> a template-generated schema of implementation classes, one per
> function interface type. The classes embody the semantics of
> closures, referring on invoke to a private method handle (as in your
> sketch). The method handle would have a signature identical to the
> erased (JVM-level) signature of the function type.
>
> Second, when a closure expression is evaluated, the compiler puts the
> code into a private method on a nearby class, and generates a method
> handle to it. (If the JVM is really accommodating, this ought to be
> an "ldc" instruction!) It then wraps the standard function-type
> around the method handle.
>
> This division is labor is in most ways better than what we get
> without method handles: The compiler must generate not just a
> private method but a whole private class, which implements a function
> type and defines an invoke method. The point of method handles (in
> this application) is to allow closure methods to be grouped naturally
> in the module that uses them, instead of spread out as 'invoke'
> methods in a bunch of inner classes.
>
> I'm sure we don't need invokedynamic (i.e., programmatically defined
> call site linkage) to implement closures, with or without method
> handles.
>
> -- John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
