Charles Oliver Nutter skrev: > I must also remark how similar this feels to LLVM's method invocation > APIs, where they toss "function" objects into the IR and it just > optimizes the calling logic. It seems to me that the new indy stuff > could be the underpinnings of a "JVM-LLVM" API that represents basic > blocks as concrete code bodies and transitions as method handle > invocations... I couldn't agree more! In fact, as long as we can limit the combinatorial explosion of method descriptors we will not even need a specific API.
Generating new code from plain Java code (with no bytecode gen) would simply be done by stringing together methods with final and bound method handles. This makes it really easy for the optimizer to inline the code. I tried to make this point in my blog earlier. Because of this, the factory methods for adapters/transforms like GuardWithTest et.al. should not be needed. (Even though there might be a utility factory for commonly used transforms somewhere.) I strongly believe that the dynamic language runtime developers and the JVM developers should stand on equal footing when it comes to creating new transforms. //Fredrik _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
