> De: "John Rose" <john.r.r...@oracle.com> > À: "Rémi Forax" <fo...@univ-mlv.fr> > Cc: "paul sandoz" <paul.san...@oracle.com>, "Da Vinci Machine Project" > <mlvm-dev@openjdk.java.net> > Envoyé: Jeudi 18 Mai 2017 21:55:30 > Objet: the End of History in the constant pool
> (I'm moving an amber-dev conversation about condy to mlvm-dev.) > We are working on a condy JEP and spec. as well as a prototype, which is > good progress. I'll post some info about that in a moment. > On May 18, 2017, at 12:16 PM, Remi Forax < fo...@univ-mlv.fr > wrote: >> I would prefer 17 to 21, because 21 is already used internally by ASM :) > I don't think anyone is objecting to 17 for CONSTANT_ConstantDynamic, > and I expect 17 is what we will land on. It's been held open for > (approximately) > this purpose. > Fun facts from History: CONSTANT_17 was used by a prototype version of > invokedynamic which was discarded. (The EG wisely discarded a couple of > designs, > including a design without method handles!) The prototype in that case > overloaded > the invokeinterface instruction, in ways which are useless to recall. In order > to make > a clean break, we helped ourselves to another constant tag. Here is my own recollection (cross checked with the SVN history of ASM), there were 4 versions of invokedynamic, the first one that was like doesNotUnderstand in SmallTalk (or method_missing of Ruby) and uses invokeinterface then the spec was rebooted, the second version has it's own bytecode 186, has method handles but has no specific constant pool constant and the bootstrap method was called with the actual values of the first call, i join the EG at that point and we worked on a the third version that was using the constant 17 and was working like invokedynamic today but has no bootstrap arguments. Happily (for invokedynamic) at that point, Sun died, so we get some the extra time to add the bootstrap arguments and uses the constant 18 to avoid to change the invokedynamic opcode because an opcode index is more precious than a constant pool tag. > Soon after that, I realized a future need for expression-like structures > threaded through the constant > pool and bootstrap specifiers, although it was a bridge too far at the time. > So > we made no effort to "compact" our constant pool tag usage, knowing there > might > be followup work in the future. > Also: From the primordial days of Java there is CONSTANT_Unicode (tag 2) > which AFAIK has never been used from JDK 1 forward. I think modern "take" on > character sets is to have one format for text (usually UTF8) and one for > binary > octets. (This is exemplified, for example, in CBOR.) I expect some day to use > the constant tag 2 for such a purpose. Basically, it would amount to giving > class > files the power to "swallow" resource files (or smaller random byte snippets). > It has an obvious multiplicative effect on condy, but we don't need it yet, so > we are going with the minimal proposal. > I think the Ultimate, End-of-History CP tags are CONSTANT_ConstantDynamic, > CONSTANT_Data, and CONSTANT_Group. > The Group is simply a subsequence of CP values (probably of limited set of > types). > It would be used for packing array constants and other aggregate types. > Today we use bootstrap specifiers, which can be as long as 2^16-1 items, > so there's no immediate motivation for a new grouping construct. But the main > point > of a Group would be to lift the restriction that all CP constants are defined > in > one > space of 2^16-1 code points. Instead, a group would contain serialized CP > entries that have no absolute CP index, but rather are loaded as part of the > group. > The group's size limit could also be raised to a u4 from u2. I think the octet > data > size limit should be u8 but that requires further API work in the JDK. My hope > is that > both Data and Group can serve at a wide range of length scales, O(10) to > O(10^10). > In the interests of incremental delivery, the forthcoming JEP only deals with > a > limited > subset of this stuff. The bug JDK-8161256 is a "kitchen sink" description of > proposals > (both live and abandoned) for futures in this direction. > — John Rémi
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
