> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Mardi 9 Avril 2019 15:39:19 > Objet: Re: Updated VM-bridges document
>>> OK, I see what you’re getting at now. Yes, this is one of the implementation >>> possibilities. I was mostly looking to validate the concepts before diving >>> into >>> the representational details. One key point is that the default case should >>> be >>> able to proceed with no bootstrap; a small set of adaptations handles the >>> most >>> important cases, and avoiding an upcall is probably pretty desirable if we >>> can >>> get away with it. >> It's an optimization, i prefer the VM to recognize a specific BSM and don't >> upcall it because its semantics is well known, it has the same effect but >> it's >> an implementation detail and not something that need to figure in the VM >> spec. > It’s an optimization, but not in the way you think. If the purity of the spec > were the only concern, then the approach you lay out would make perfect sense. > But, there are other engineering realities, and taking on the full cost of > bootstrap upcalls at this particular place in the VM — when we don’t have to > yet — may well be a significant (and not yet necessary) engineering effort. It doesn't seem wise to directly calls the BSM when you are filling the vtable but you can always generate an adapter (the descriptors from and to are known statically) that will call the BSM and replace itself. A strawman implementation is to generate during the parsing of the classfile, for each VM bridge a Java method with a bytecodes that does an invokedynamic call, the invokedynamic BSM taking as parameter the VM bridge BSM. Rémi
