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