Closure implementation

[Osvaldo Pinali Doederlein]

Em 15/12/2009 17:20, Neal Gafter escreveu:
> On Tue, Dec 15, 2009 at 10:03 AM, Osvaldo Doederlein 
> <opinali at gmail.com <mailto:opinali at gmail.com>> wrote:
>
>     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.

I really meant anonymous classes, I just assumed this would be in the 
scope of 292 because the original motivation was support for 
dynamic-typed languages (long time since I've checked the EDR, not 
following 292's list...). I realize that the space & loading costs are 
small; but then, the same holds for the helper classes generated by many 
dynamic langs. Of course the latter tend to produce a much higher number 
of such classes; but then, I (somewhat optimistically) envision a future 
with next-generation frameworks and DSLs abusing closures... if I ever 
have five closures per method and fifty per class, even if that's just 
in niche usages, any savings are significant, even with a better 
packaging format.

>     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.

I didn't see any impediment to the desired optimizations; I was just 
worried that it could exist somewhere I didn't notice. But your feedback 
clears these worries.

> 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.

I didn't took the time to consider MethodHandles, that was not among my 
suggestions. MHIs and closures are both special interfaces, so that's 
likely another item in the wish-list of optimizations that I hope 
somebody, sometime, will do - I'm not able to provide a significant 
contribution for this, certainly not in the current JDK7 schedule.

A+
Osvaldo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091216/e25d5737/attachment.html