On May 19, 2009, at 1:00 AM, Rémi Forax wrote: > The purpose of primitive adapters is to hep the language developer > to fight > the inherent complexity of dealing with polymorphic signature.
Yes, that's the key point. As Fredrik says, you can hide the polymorphism by going to a reflective (fully boxed) calling sequence. But, we've had 10 years to learn to optimize that reliably, and we don't. Some JVMs optimize boxing sometimes, but not all do, and it is historically a hard problem. A goal of the present design is for the new facilities to support the full range of JVM calling sequences, including native (unboxed) primitives. The set of combinators in MHs is not minimal, but it is only a step or two away (I hope) from being tasteful. If a JVM has excellent boxing analysis, then it can implement these combinators very easily on top of Lisp-y rest-args. But we can't presume that for all JVMs. The combineArguments combinator is both polymorphic and pretty nearly universal (without boxing). I hope to implement it mostly "in the metal", under the name "flyby adapter". The idea is you get a subroutine to witness the full argument list and make some computation, the result of which is injected back into the argument list before the ultimate target is called. If the injected value is itself a method handle, and the ultimate target is MH.invoke, then we have the makings of a threaded interpreter, all inside a method handle nest. Therefore, inlinable in the LLVM sense. I expect to implement guardWithTest on top of combineArguments. -- John _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
