FYI: LambdaForm-based java.lang.invoke implementation overview

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Tue Feb 24 10:09:38 UTC 2015


John, thanks a lot for the feedback!

Updated the slides in place:
http://cr.openjdk.java.net/~vlivanov/talks/2015-Indy_Deep_Dive.pdf

> Error on slide 12: invokespecial *has* a receiver.  While I'm tweaking, I suppose you could say "single dispatch (via table)" vs. "single dispatch (via search)", but that's a matter of debate.
Whoo! Fixed.

> Slide 13: optional static arguments are probably TMI on the first slide showing a BSM; they might confuse people into thinking they are dynamic (normal) arguments.  Suggest a slide 13.5 which introduces static and dynamic arguments at the same time.
Done (slide #17).

> Slide 49: /vmindex from symbolic link/s/link/reference/ ("symbolic link" is not a spec. term)
Fixed.

> Slide 54: The javadoc is messy; you quote it correctly.  But, while prim/ref conversion is casting (5.5), it is *also* assignment (5.2); the non-error actions are the same in the prim/ref case.  (MHs.explicitCastArguments uses additional types of casting.)  I think the only reason we mention 5.5 here instead of 5.2 is an accident during spec creation; we may have briefly an erroneous ref-to-ref cast after the boxing operation.  Probably it's worth a footnote, saying something like "assignment (5.2)*  ...  *spec says casting (5.5) which mandates the same behavior for the prim/ref case".
Thanks for the clarifications. Updated the slide as you suggested.

> Slide 64: Informative rendering of an LF to bytecodes.  Wouldn't it be cool to have have a slide 64.5 of a representative MH compiled to MH-customized native code...  (That opens up the whole big question of share-vs-customized, but still would be nice to see object code.)
Do you suggest to show rendered bytecode for MH-customized LambdaForms 
or demonstrate native code?

> Slide 78: invokeExact_000_MT should renumber the temps; you apparently inserted a2/a3 but did not change t2/t3 to t4/t5.
Fixed.

> Slide 85: s/invokeGeneric linkage/invokeExact linkage/  (there is no invokeGeneric in the spec, though there was at one point)
Fixed.

> Slides 86-89:  You have just C frames, which don't give enough context.  Suggest appending younger frames to the stack trace.
Agree. Done.

> Slide 90: Maybe give a use case for each annotation?
Done.

Best regards,
Vladimir Ivanov


More information about the mlvm-dev mailing list