On Jan 17, 2008 6:30 AM, John Wilson <[EMAIL PROTECTED]> wrote: > One thing I have considered is aggregating all these > closures/lambda/etc in a compilation unit as static methods on a > single class. This means that you amortise the cost of a classloader > over several methods. Instances of the function object delegate to the > static method. The cost is, obviously, delayed GC of the "mothership" > class. Of course, if you can dynamically create new functions this > won't help.
That's what I'm doing. Function is an abstract class rather than a marker interface, and it provides a field named _index. If Foo is a subclass of Function that has five static methods, then there are also five static fields initialized to five instances of Foo with _index values from 0 to 4; these represent at source-language level the five possible functions (in general, there may be more than one Foo per source-code module, but one is typical). So if you invoke the _invoke method (the only instance method of these classes) on a particular Foo object, it will run a switch statement that validates the number of passed arguments and calls the appropriate static function. This is only done, of course, when the function to be invoked is not known at compile time; otherwise, the static method is called directly. Currently this is only done for top-level functions. Nested functions (which are all anonymous) use Java anonymous classes (subclasses of Function that implement _invoke), but I may change this to do lambda-lifting instead. Does anyone have any insights about the pros and cons of lambda-lifting on the JVM? Can I do substantially better than the Java compiler? (Note that I am generating Java, not bytecode, and that all mutable local variables have already been converted to point to boxes.) -- GMail doesn't have rotating .sigs, but you can see mine at http://www.ccil.org/~cowan/signatures --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
