<div class="gmail_quote">On Tue, Dec 15, 2009 at 10:03 AM, Osvaldo Doederlein <span dir="ltr">&lt;<a href="mailto:opinali@gmail.com" target="_blank">opinali@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



I was wondering about the implementation of closures (translation into Java bytecode), a topic that&#39;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&#39;s perhaps early to worry about implementation, but the exception if some implementation requirement demand support from the language spec.<br>



</blockquote><div><br>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.<br>



<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


I wish closures to be as lightweight as possible. This means:<br><br>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&#39;s anonymous classes, so each synthetic closure class doesn&#39;t load unnecessary metadata.<br>



</blockquote><div><br>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.<br>



<br>The 292 EDR doesn&#39;t describe anonymous classes.  Do you mean method handles?  It isn&#39;t clear that code generated to 292&#39;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.<br>



<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


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&#39;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.<br>



</blockquote><div><br>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.<br>



<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


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



</blockquote><div><br>Agreed.  That was why I took issue with Mark&#39;s assertion to the contrary (that each evaluation of a lambda would produce a distinct object).<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



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&#39;re so bloated; closures (as powerful as BGGA or CfJ 0.6a+b) will be even more bloated.</blockquote>



<div><br>I&#39;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.<br>



<br>It isn&#39;t clear how to use jsr292&#39;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&#39;m afraid I can&#39;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.<br>



<br>Cheers,<br>Neal<br><br></div></div>