Hi John, Thanks for moving the conversation to mlvm-dev! The condy stuff is finally coming, yay!
Just out of curiousity, since we're on this topic, may I ask about what constant tags 13 and 14 used to mean? All I could find was that 13 was used in JavaCard VM (JCVM) as CONSTANT_Package. But what was the full story behind the missing 13 and 14 here? Thanks, Kris On Thu, May 18, 2017 at 12:55 PM, John Rose <john.r.r...@oracle.com> wrote: > (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. 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 > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > >
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
