Reduce number of classes generated with MethodHandles/invokedynamic

[rahulmutt]

Should be done after #322. Same example will be used:

package main;

public class Main {
  public StgClosure add_closure = new add();
  public static class add {
    public void enter(StgContext context) {
      StgClosure x = context.R(2);
      StgClosure y = context.R(3);
      add_entry(context, x, y);
    }
  }
  public static void add_entry(StgContext context, StgClosure x, StgClosure y) {
    // Non-trivial part of entry code
  }
}

It seems like the code for enter in the add class is pretty common and any top-level function that takes two argument will have the exact same form with the difference being the static method that is called at the end. If we can find a way to abstract over that, we can reduce the number of classes we generate significantly (but we might take a slight hit in performance?) which is a win for platforms like Android that have method limits.

Here's an SO post that outlines the different ways of handling the problem. To summarise:

1. Generate the class at runtime - Looks promising but may add to startup time. The generation should happen when creating the closure for the first time when populating the private closure fields.
2. Use reflection - OK but not too happy about the potential performance hit.
3. Use method handles/using the lambda factory methods in Java 8 - Perfect solution for the problem but forces Java 8 on the users.

I think a balance between 1 & 3 is the ideal solution. Something like - use the lambda factory methods if Java 8 is there, otherwise fallback on (1) which is backwards compatible.

[mikehearn]

Note that the java 8 lambda/methodhandles infrastructure uses code generation behind the scenes. But invokedynamic is definitely the way to go here. You can use it in many places in a project like eta, I think. It's a very powerful instruction.

[rahulmutt]

Yes and MethodHandle's are something the JIT knows how to optimise (Java 8+) so it's a performance win as well. Will definitely add an -indy flag to the compiler that will generate code based on MethodHandle's and teach etlas to download the right jar binary based on the java version that is being used.

[rahulmutt]

Runtime class generation kills Eta's options on Android which disallows it (might have changed in recent versions). The best approach here is to generate an invokedynamic instruction that returns a constant call site that points to add_entry.