the End of History in the constant pool

[Krystal Mok]

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.rose at 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 <forax at 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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20170518/073d0e43/attachment-0001.html>