Indeed. I did actually start toying with an implementing of this after the summit, but I quickly run into the problem of missing implementations of important intrinsic method handles - I would have needed guardWithTest, insertArgument, and collectArguments for a monomorphic cache, a collectArguments for varargs, and so on. All I had to work with was Rémi's backport, which doesn't (yet) implement these, so I shelved it for the time being, but the overall direction seems to be valid.
On a sidenote, I would also be a happy user of a prebuilt MLVM binary (for Mac OS X, no less; alternatively, I might really look into installing OpenSolaris into VMWare). Attila. On 2009.01.21., at 20:56, John Rose wrote: > As Attila said at the Summit in September, this new stuff probably > has strong implications on the design of a MOP. The main example is > using method handles to express units of procedural semantics; the > MOP's job of handing out such units is streamlined if those units can > be directly invoked (as in invokevirtual or invokedynamic) by the MOP > client, instead of called through a reflective veil of boxed > varargs. Getting this working requires that the client code which > uses the MOP must be able to emit method handle calls. If the Java > language supports these things, then the MOP clients can be written > using javac not just ASM, which makes a JSR 292-based MOP viable. > > -- John --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
