Closure implementation

[Neal Gafter]

On Tue, Dec 15, 2009 at 10:03 AM, Osvaldo Doederlein <opinali at gmail.com>wrote:

> I was wondering about the implementation of closures (translation into Java
> bytecode), a topic that's not yet covered by any of the current proposals
> (CfJ 0.6a+b or the Strawman), although well illustrated by the BGGA
> prototype. It's perhaps early to worry about implementation, but the
> exception if some implementation requirement demand support from the
> language spec.
>

The CFJ spec is clear that function types are interfaces.  Other than that,
the implementation of the interface generated by the compiler for a lambda
is not constrained.  It could even vary from compiler to compiler or from
lambda to lambda.

I wish closures to be as lightweight as possible. This means:
>
> a) The classes that closures are translated to, should be as small and fast
> to load as possible. These classes could benefit from JSR-292's anonymous
> classes, so each synthetic closure class doesn't load unnecessary metadata.
>

My understanding is that most of the cost comes from the methods, not the
class.  In any case, loading is a one-time thing.  SE 7 will improve that
with a new format for use instead of jar files.

The 292 EDR doesn't describe anonymous classes.  Do you mean method
handles?  It isn't clear that code generated to 292's method handles would
actually be faster, but without a proposal on how to do it all we can do is
guess.  I strongly encourage you to suggest a form for the specification and
implementation that would do that.

b) The compiler should be able to shortcut closure classes whenever
> possible. This is important for multiple use cases, from control structures
> (like in CfJ 0.6b) to Smalltalk-like extension methods for collections
> (select(), etc.). I'd expect a sufficiently smart compiler to translate the
> calls to such methods (and their literal-closure parameters) into fully
> inline code without any overhead of synthetic classes/methods. For control
> structures with non-local transfer, such optimization, when possible, would
> remove the bulky code and helper exceptions that we see in the BGGA
> prototype.
>

Inlining is possible either in the VM, or by javac for methods specified as
part of Java SE.  The latter would be useful in conjunction with CFJ part b
for things like ARM blocks, which could then be platform-provided APIs
instead of a language extension.

c) For closures that cannot be optimized out and must be represented as
> runtime classes/objects, I'd expect a best-effort to optimize that
> representation. Remarkably, if the closure doesn't capture any state from
> the enclosing instance, I expect javac to generate a singleton object so
> there's no overhead to allocate a separate closure object at each execution.
>

Agreed.  That was why I took issue with Mark's assertion to the contrary
(that each evaluation of a lambda would produce a distinct object).


> Lightweight closures are very important for any usage that involves
> abundant, fine-grained closures. One of my old pet peeves with Java inner
> classes is that they're so bloated; closures (as powerful as BGGA or CfJ
> 0.6a+b) will be even more bloated.


I'm not sure in what sense you see those specifications as requiring weight
in the implementation.  Inner classes are certainly bloated in source, and
have some start-up-time impact, but the objects themselves are small and
fast to create and invoke.

It isn't clear how to use jsr292's method handles to specify and implement a
language construct compatible with the strawman, or what the overhead of
such a solution would be.  I think such a research project would be a very
worthy undertaking, though I'm afraid I can't allocate my own time to the
task.  If it is to be done in time for SE 7 (specified, implemented, and
integrated by the beginning of June), then whoever wants to make it happen
(is that you, Osvaldo?) should probably start immediately.  I will be happy
to provide as much feeedback as my time allows.

Cheers,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091215/95084262/attachment.html