That is all an optimization that can come a *lot* later, though, and should only be adopted after proving they are actually gains. Start simple. The perfect is the enemy of the good.
By the time you get to that point, Java 7 will be out with MethodHandles and invokedynamic, and you'll really, *really* want to look into them over and against any kind of reflection hackery, no matter how optimized. ~~ Robert. On Tue, May 17, 2011 at 11:02 AM, John Cowan <[email protected]> wrote: > On Tue, May 17, 2011 at 9:15 AM, Alexander Bertram > <[email protected]> wrote: > >> My question for the JVM-niks out there is how feasable is it create a >> new jvm class for each thunk or function value? >> When you write a function in scala or clojure, does this get compiled >> into a new, separate class? >> >> I know invokedynamic will solve a lot of these problems, but in >> targeting java 6, is it worth economizing on the number of class, >> using for example reflection to dispatch a function call to a static >> method? > > FWIU, the optimal approach if you are batch-compiling is to stuff N > functions into a single class as static methods using this sort of > framework: > > public class FooBarBaz { > private int _function; > private FooBarBaz(function) { _function = function; } > public static final fooFunction = new FooBarBaz(0); > public static final barFunction = new FooBarBaz(1); > public static final bazFunction = new FooBarBaz(2); > private static Object foo(Object arg) { ... } > private static Object bar(Object arg) { ... } > private static Object baz(Object arg) { ... } > public Object apply(Object arg) { > switch (_function) { > case 0: return fooFunction(arg); > case 1: return barFunction(arg); > case 2: return bazFunction(arg); > } > } > > Note that all functions in a given class need to have the same > Java-level type signature. You can avoid this by using Object[]s, but > that's additional overhead. > > This approach lets you run with no reflection overhead, and hopefully > the static methods will be inlined by the JIT (if not, you can inline > them yourself). You also reduce the number of classes by a > (potentially large) linear factor, which holds down on permgen > consumption. > > -- > 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. > > -- 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.
