On Wed, Dec 17, 2008 at 10:09 PM, John Rose <[email protected]> wrote: > The most recent version of JVM specs. (headed for HotSpot integration > RSN) is here for engineering review: > http://webrev.invokedynamic.info/jrose/6655638.meth/ > > That review copy is changing also; it's now a month old.
John, thanks for your answers. I had a look and things things become clearer. We have two targets right now: short term, to evaluate performance relative to reflection, and long term, to update the Scala compiler to use the new features of the JVM. The short term goal is for a paper about structural subtyping in Scala, due this Saturday :D. That means we are stuck with the current state of the implementation. For the long term goal, we'd be very interested to 'be in the loop' and try things early. > The new instruction is (almost certainly) going to use the previously- > unused bytecode point 0xba, will be a five-byte format with a two- > byte CONSTANT_NameAndType index followed by two MBZ padding bytes > (for possible interpreter use). The type Dynamic (charming as it is) > does not play a role in the bytecodes. This is where we're heading. But the current implementation is using the JSR292 convention, so for my tests I should still use it? >>> The contract of 'bootstrap' is that it makes the call and returns a >>> value, possibly setting a target for future calls. In the current >>> implementation, one would have to create a new array and strip the >>> first element: >>> >>> cs.setTarget(mh); >>> Object[] args1 = new Object[args.length - 1]; >>> System.arraycopy(args, 1, args1, 0, args.length - 1); >>> return rm.invoke(args[0], args1); >>> >>> I find this to be a typical scenario, so I wonder why this deviation >>> from the JSR. > > It never made perfect sense to do things this way, because many dyn. > langs. (see Groovy) use static methods as units of pluggable > behavior. But it was that way because the syntax for invokedynamic > was receiver-based. Now it is completely symmetric in all arguments. Unfortunately (for us), Scala takes an opposite stance: there are no static methods. But we can live with a slow first call, since we should be able to resolve most calls and install a target. I noticed a very useful method mentioned in the JSR is missing from the implementation, MethodHandles.guardWithTest. I hope it will make its way into the new spec. Our use case for invoke dynamic is to resolve calls to methods we know they exist in the receiver, but the receiver type does not show it. Resolved call sites are very likely to change, as the receiver class might change, so it would be great to have more fine grained control over invalidating call sites. >> You can directly call a MethodHandle without put object in a array >> by calling a invoke method with any arguments you want: >> MethodHandle mh=... >> mh.invoke(3,"foo"); // here 3 is not boxed > > You may also prefer to write signature-polymorphic code. (Write > once, run every case more slowly.) To support this, the newest spec > for method handles has a "varargs" bit on MethodType and appropriate > adapter constructors. So it's easy to spread or gather argument > groups, independently of the reflective API, or in concert with it. I see. I wanted to avoid changes in the type checker to treat MethodHandle.invoke as special. But maybe that's the best solution. One last question: does mlvm currently recognize the BootstrapInvokeDynamic classfile attribute? My tests were unsuccessful, so I'm wondering if my code generator is wrong, or I need to resort to static initializers. Thanks, iulian -- « Je déteste la montagne, ça cache le paysage » Alphonse Allais _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
