On Dec 17, 2008, at 12:13 PM, Rémi Forax wrote: > Iulian Dragos a écrit : >> I noticed several differences between what JSR 292 >> (http://jcp.org/en/jsr/detail?id=292) says and the current >> implementation. I know this is work in progress, but at least one >> difference seems small enough to be an oversight.
Iulian: I'm very glad you are looking at the spec. and HotSpot implementation, and I apologize for the incomplete state of both. It's going to get better soon. 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. > Currently, the first draft of the spec is outdated > and the implemntation is not up to date too. That's right, Remi. I'm working furiously on both spec. and implem. furiously, aiming to get a refresh of both by Christmas. Until engineering and JSR 292 Expert Group reviews are complete, both are moving targets, of course. But Remi is correct on all points. > The current idea is to implement invokedynamic like invokestatic, > i.e without a receiver. This was the outcome of Summit conversations; I initially resisted this but then flip-flopped after realizing the community has plenty of months to adjust to a new instruction, and many more years to regret a design compromise on that point. 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. The langtools branch of the mlvm repo. has a trial version of javac (meth.patch) that emits a couple of different syntaxes of invokedynamic. The next rev. will remove the unused syntaxes. There is a provisional syntax for issuing invokedynamic calls from Java that looks like a call to a static method on the interface Dynamic: java.dyn.Dynamic.<boolean>foo((int)x, (char[])y, (Object)z); // invokedynamic foo(I[CLjava/lang/Object;)Z To generate a method handle calls, just issue a virtual call to 'invoke' with an arbitrary signature. The polymorphic signature requires another small javac change; the invoke method appears to be parameterized by the method return type, as with invokedynamic. See: http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/meth.txt (watch typo: type param is after dot) http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/meth.patch >> 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. > 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. Best wishes, -- John _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
