Thanks for looking at the code. It needs a thorough review. BTW, I am working to add VM support for flyby adapters; when this works I'll *remove* many of the repetitive cases in *Generic.java.
On Jun 10, 2009, at 4:57 AM, Rémi Forax wrote: > Hi John, I've just quickly take a loook to your code. > I've notice that you appendan enum value LIMIT at the end > like in C to know how many enums values are defined, > in Java, you can use values() instead. > Ok, it create an array but only once. I'd prefer to do that, but I'd have to replace the second use of LIMIT at the top of the file, and don't know a similarly clean alternative. The problem is that the enum encapsulates indexing of a 2-D array. > A question: > The JSR292 backport contains a similar code, > http://code.google.com/p/jvm-language-runtime/source/browse/trunk/invokedynamic-backport/src/jsr292/java/dyn/MHInserter.java > but use a switch instead of one class by argument value. > I was wondering if the VM was able to remove that switch ? I don't think that your switch will be removed, since it requires constant folding of a non-static field, which is rare; the same would be true of if/then/else. You could try if/then/else as an alternative. Or, you could type-split MHInserter into MHInserter_0, MHInserter_{1,2,N}, and do your own partial evaluation. You could do this without code copying by virtualizing the switch selection expression: - switch (position) { + switch (position()) { - class MHInserter extends MethodHandle + abstract class MHInserter extends MethodHandle - private final int position; - protected abstract int position(); Three specialized cases, plus a fallback class plus an abstract class to hold the code: That's probably enough. -- John P.S. Your code is very clean; I like it. A naming nit: "droper" should be "dropper". _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
