ClosuresAndMethodHandles - Revision history

JaroslavTulach: /* Just Implementation */

JaroslavTulach — Sat, 12 Dec 2009 20:17:07 GMT

Just Implementation

←Older revision		Revision as of 20:17, 12 December 2009
Line 101:		Line 101:
	=== Just Implementation ===		=== Just Implementation ===

-	The above example shows only the internals of the implementation. It does not prescribe at all how the actual [[closures]] syntax is going to look like. It does not matter. If the [[closures]] can be expressed as anonymous innerclasses, ~~they~~ will be ~~expressible~~ via [[ClosuresAndMethodHandles\|method handles]] too.	+	The above example shows only the internals of the [[closures]] implementation. It does not prescribe at all how the actual [[closures]] syntax is going to look like. It does not matter. If the [[closures]] can be expressed as anonymous innerclasses, it will be possible to express them via [[ClosuresAndMethodHandles\|method handles]] too.

	Especially following is unaffected: The classical [[closures]] proposals usually operate with a ''closure conversion'' - e.g. that a closure can be converted into an existing interface. So one can call:		Especially following is unaffected: The classical [[closures]] proposals usually operate with a ''closure conversion'' - e.g. that a closure can be converted into an existing interface. So one can call:

JaroslavTulach: /* ClosuresAndMethodHandles */

JaroslavTulach — Sat, 12 Dec 2009 20:15:20 GMT

ClosuresAndMethodHandles

←Older revision		Revision as of 20:15, 12 December 2009
Line 98:		Line 98:

	Also, in all the [[closures]] for [[Java]] specifications, the '''this''' is treated differently than in inner classes. It is supposed to mean the outer class, which would require certain compiler transformations if [[closures]] were implemented as hidden inner classes. If [[closures]] are implemented as method handles, the meaning of '''this''' naturally stays the same, as the methods are really methods of the proper class.		Also, in all the [[closures]] for [[Java]] specifications, the '''this''' is treated differently than in inner classes. It is supposed to mean the outer class, which would require certain compiler transformations if [[closures]] were implemented as hidden inner classes. If [[closures]] are implemented as method handles, the meaning of '''this''' naturally stays the same, as the methods are really methods of the proper class.
		+
		+	=== Just Implementation ===
		+
		+	The above example shows only the internals of the implementation. It does not prescribe at all how the actual [[closures]] syntax is going to look like. It does not matter. If the [[closures]] can be expressed as anonymous innerclasses, they will be expressible via [[ClosuresAndMethodHandles\|method handles]] too.
		+
		+	Especially following is unaffected: The classical [[closures]] proposals usually operate with a ''closure conversion'' - e.g. that a closure can be converted into an existing interface. So one can call:
		+
		+	<source lang="java">
		+	void sayHello(java.util.concurrent.Executor ex) {
		+	ex.execute(#(){ System.out.println("hello"); });
		+	}
		+	</source>
		+
		+	This still remains possible. It is just necessary to know how to convert some ''MethodHandle'' into ''Runnable''. But one factory method can indeed do it (including arity and parameter types check). So the expressiveness of [[closures]] is in no way affected by using [[ClosuresAndMethodHandles\|method handles]].

	=== Related External References ===		=== Related External References ===

JaroslavTulach at 07:23, 2 December 2009

JaroslavTulach — Wed, 02 Dec 2009 07:23:21 GMT

←Older revision		Revision as of 07:23, 2 December 2009
Line 101:		Line 101:
	=== Related External References ===		=== Related External References ===

-	* [http://weblogs.java.net/blog/2008/01/16/yet-another-closure-proposal Remi Forax]'s proposal	+	* [http://weblogs.java.net/blog/2008/01/16/yet-another-closure-proposal Remi Forax]'s syntax proposal
		+	<!--
	* [http://blogs.sun.com/jrose/entry/notes_on_an_architecture_for John Rose]'s note about closures		* [http://blogs.sun.com/jrose/entry/notes_on_an_architecture_for John Rose]'s note about closures
		+	-->

JaroslavTulach at 05:55, 2 December 2009

JaroslavTulach — Wed, 02 Dec 2009 05:55:53 GMT

←Older revision		Revision as of 05:55, 2 December 2009
Line 98:		Line 98:

	Also, in all the [[closures]] for [[Java]] specifications, the '''this''' is treated differently than in inner classes. It is supposed to mean the outer class, which would require certain compiler transformations if [[closures]] were implemented as hidden inner classes. If [[closures]] are implemented as method handles, the meaning of '''this''' naturally stays the same, as the methods are really methods of the proper class.		Also, in all the [[closures]] for [[Java]] specifications, the '''this''' is treated differently than in inner classes. It is supposed to mean the outer class, which would require certain compiler transformations if [[closures]] were implemented as hidden inner classes. If [[closures]] are implemented as method handles, the meaning of '''this''' naturally stays the same, as the methods are really methods of the proper class.
		+
		+	=== Related External References ===
		+
		+	* [http://weblogs.java.net/blog/2008/01/16/yet-another-closure-proposal Remi Forax]'s proposal
		+	* [http://blogs.sun.com/jrose/entry/notes_on_an_architecture_for John Rose]'s note about closures

JaroslavTulach: /* ClosuresAndMethodHandles */

JaroslavTulach — Wed, 02 Dec 2009 05:50:43 GMT

ClosuresAndMethodHandles

←Older revision		Revision as of 05:50, 2 December 2009
Line 64:		Line 64:
	public void sayHello(final String to) {		public void sayHello(final String to) {
	MethodHandle addThis = MethodHandles.insertArgument(first, 0, this);		MethodHandle addThis = MethodHandles.insertArgument(first, 0, this);
-	withLock(~~first~~);	+	withLock(addThis);
	MethodHandle applyToAndThis =		MethodHandle applyToAndThis =
	MethodHandle.insertArgument(MethodHandles.insertArgument(second, 0, to), 0, this);		MethodHandle.insertArgument(MethodHandles.insertArgument(second, 0, to), 0, this);
-	withLock(~~second~~);	+	withLock(applyToAndThis);
	}		}

JaroslavTulach: /* The Mapping */

JaroslavTulach — Tue, 01 Dec 2009 11:21:39 GMT

The Mapping

←Older revision		Revision as of 11:21, 1 December 2009
Line 53:		Line 53:
	Even this simple example shows how ineffective trivial implementation of [[closures]] can be. Instead of one class, we have three. Each of them having significant overlaps in their constant pools. Given the expected proliferation of closure based [[API]]s (as they are easy to use, much easier than innerclasses), this can lead to enormous and unnecessary waste of memory. As one who watches over [[performance]] of [[NetBeans]] I cannot silently let this happen.		Even this simple example shows how ineffective trivial implementation of [[closures]] can be. Instead of one class, we have three. Each of them having significant overlaps in their constant pools. Given the expected proliferation of closure based [[API]]s (as they are easy to use, much easier than innerclasses), this can lead to enormous and unnecessary waste of memory. As one who watches over [[performance]] of [[NetBeans]] I cannot silently let this happen.

-	=== ~~The Mapping~~ ===	+	=== [[ClosuresAndMethodHandles]] ===

	Thankfully there is a cure. It is possible to write well performing implementation of [[closures]] using [[invokeDynamic]] and its method handles. Imagine that the above code is rewritten to use method handles (and that the withLock method now takes MethodHandle):		Thankfully there is a cure. It is possible to write well performing implementation of [[closures]] using [[invokeDynamic]] and its method handles. Imagine that the above code is rewritten to use method handles (and that the withLock method now takes MethodHandle):

JaroslavTulach: New page: === Method Handle === {{:InvokeDynamic}} === Closures as innerclasses === The typical expectation for implementing closures (for example the [http://javac.info...

JaroslavTulach — Tue, 01 Dec 2009 09:55:37 GMT

New page: === Method Handle === {{:InvokeDynamic}} === Closures as innerclasses === The typical expectation for implementing closures (for example the [http://javac.info...

New page

=== [[InvokeDynamic|Method Handle]] ===

{{:InvokeDynamic}}

=== [[Closures]] as innerclasses ===

The typical expectation for implementing [[closures]] (for example the [http://javac.info/closures-v06a.html 0.6a version]) seems to envision a closure as an innerclass (if it says at all, how [[closures]] shall be implemented), with simplified syntax. This is indeed possible, yet ineffective. Overhead of defining new (inner) class in [[Java]] is high. Each class occupies a single .class file and these files are selfcontained. They contain not only their code, but also all their static linking information (e.g. the constant pool). This information gets copied with each inner class. Splitting one class into three does not keep the final size proportional to the original one. Imagine you want to rewrite following code:

<source lang="java">
class SayHello {
public void sayHello(String to) {
String hello = "hello";

System.out.println(hello);
System.out.println(to);
}
}
</source>

so that each of the printlns runs under some lock (let's expect there there is some static method withLock(Runnable) and that we can use some form of [[closures]]):

<source lang="java">
class SayHelloSafely {
public void sayHello(String to) {
String hello = "hello";

withLock({ System.out.println(hello); });
withLock({ System.out.println(to); });
}
}
</source>

Due to power of [[closures]] this code is as simple as the original one (just the call to ''withLock'' is added, but that was intended change to satisfy our goal). However if we stick with the originally planned implementation of [[closures]] as inner classes, then the above code in fact means:

<source lang="java">
class SayHelloSafely {
public void sayHello(final String to) {
final String hello = "hello";
withLock(new Runnable() {
public void run() {
System.out.println(hello);
}
});
withLock(new Runnable() {
public void run() {
System.out.println(to);
}
});
}
}
</source>

Even this simple example shows how ineffective trivial implementation of [[closures]] can be. Instead of one class, we have three. Each of them having significant overlaps in their constant pools. Given the expected proliferation of closure based [[API]]s (as they are easy to use, much easier than innerclasses), this can lead to enormous and unnecessary waste of memory. As one who watches over [[performance]] of [[NetBeans]] I cannot silently let this happen.

=== The Mapping ===

Thankfully there is a cure. It is possible to write well performing implementation of [[closures]] using [[invokeDynamic]] and its method handles. Imagine that the above code is rewritten to use method handles (and that the withLock method now takes MethodHandle):

<source lang="java">
class SayHelloEffectively {
private static MethodHandle first;
private static MethodHandle second;

public void sayHello(final String to) {
MethodHandle addThis = MethodHandles.insertArgument(first, 0, this);
withLock(first);
MethodHandle applyToAndThis =
MethodHandle.insertArgument(MethodHandles.insertArgument(second, 0, to), 0, this);
withLock(second);
}

private void firstRunnable() {
final String hello = "hello";
System.out.println(hello);
}
private void secondRunnable(String to) {
System.out.println(to);
}

static {
first = MethodHandles.lookup().findSpecial(
SayHelloEffectively.class, "firstRunnable",
MethodHandles.methodType(void.class)
);
second = MethodHandles.lookup().findSpecial(
SayHelloEffectively.class, "secondRunnable",
MethodHandles.methodType(void.class, String.class)
);
}
}
</source>

Please accept my appology for the above use of method handling [[API]]. It is just a sketch of the implementation. I have not found the javadoc to verify or even compile my code against it. Anyway it is clear that this conversion of [[closures]] is very constant pool friendly. Regardless of the amount of [[closures]] in a class, just one, shared constant pool is used. This avoids useless duplication of its entries in the inner classes.

The method handle solution shall also be well performant. Method handle combinators are supposed to be effective. The only slow operation is the reflective binding, but that happens just once, when the class is loaded (or the method is first used).

Also notice that this approach really supports [[closures]]. If a piece of code references some variable from outer block, it is easy (because of method handle combinators) to pass such variable into the closure method via an argument. Sort of like partially applied functions in high level languages.

Also, in all the [[closures]] for [[Java]] specifications, the '''this''' is treated differently than in inner classes. It is supposed to mean the outer class, which would require certain compiler transformations if [[closures]] were implemented as hidden inner classes. If [[closures]] are implemented as method handles, the meaning of '''this''' naturally stays the same, as the methods are really methods of the proper class.