Re: the End of History in the constant pool

[John Rose]

On May 18, 2017, at 6:55 PM, Mark Roos  wrote:
> 
> Does this allow the use of a byteArray as one or more of the bootstrap 
> constants? 
> 
> I seem to recall that was something I wished for when I did a similar effort 
> with 
> constant call sites. 

Yes, it does.  The byte array would be its own condy node, which could then
be used as a BSM argument.  This is why condy is more than just a slightly
better way to do indy-of-no-arguments.

Also, by tweaking MH.invokeWithArguments to support thousands of arguments,
the set of possible BSM argument lists is much more interesting (limited to 64k
at present, until we get Groups).

— John
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: the End of History in the constant pool

[Mark Roos]

Hi John,

Does this allow the use of a byteArray
as one or more of the bootstrap constants?

I seem to recall that was something
I wished for when I did a similar effort with 
constant call sites.

mark
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: the End of History in the constant pool

[John Rose]

On May 18, 2017, at 2:13 PM, fo...@univ-mlv.fr wrote:
> 
> uses invokeinterface then the spec was rebooted, the second version has it's 
> own bytecode 186,

There was another in between that used invokeinterface and reified a CallSite 
with
patchable state.  I did a really nasty design for this w/o MHs, but it was like 
cooking
blindfolded.
— John___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: 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  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  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

Re: the End of History in the constant pool

[John Rose]

On May 18, 2017, at 12:55 PM, John Rose  wrote:
> 
>  I'll post some info about that in a moment.

Here's what we are thinking about doing with condy in the short term.
Comments are welcome.  This work is landing in branches of the Amber
project.

— John

Just as the linkage of an invokedynamic call site involves an upcall
from the JVM to Java-based linkage logic, we can apply this same trick
to the resolution of a constant pool entry. A CONSTANT_Dynamic
constant pool entry encodes the bootstrap method to perform the
resolution (a MethodHandle), the type of the constant (a Class), and
any static bootstrap arguments (an arbitrary sequence of constants,
barring cycles in the CP between dynamic constants.)

We add a new constant pool form, CONSTANT_Dynamic (new constant tag
17), which has two components following its tag byte: the index of a
bootstrap method, in the same format as the index found in a
CONSTANT_InvokeDynamic, and a CONSTANT_NameAndType) which encodes the
expected type.

Behaviorally, a CONSTANT_Dynamic constant is resolved by executing its
bootstrap method on the following parameters: 1. a local Lookup
object, 2. the String representing the name component of the constant,
3. the Classrepresenting the expected constant type, and 4. any
remaining bootstrap arguments. As with invokedynamic, multiple threads
can race to resolve, but a unique winner will be chosen and any other
contending answers discarded. Instead of returning a CallSite object
(as the invokedynamicinstruction requires) the bootstrap method would
return a value which would be immediately converted to the required
type.

As with invokedynamic, the name component is an additional channel,
besides the type, for passing expression information to the bootstrap
method. It is expected that just as invokedynamic instructions find
uses for the name component (e.g., a method name or some ad hoc
descriptor) dynamic constants will also find uses for the name (e.g.,
the name of a enum constant or the spelling of a symbolic
constant). Putting the CONSTANT_NameAndTypein both places makes for a
more regular design. In effect, a CONSTANT_Methodref and
CONSTANT_Fieldref constants are used to refer to named members of
classes, while the analogous CONSTANT_InvokeDynamic and
CONSTANT_Dynamic constants are used to refer to named entities with
user-programmed bootstraps.

The type component of the constant, with both invokedynamic
andCONSTANT_Dynamic, determines the effective type of the call site or
constant (respectively). The bootstrap method does not contribute or
constrain this type information, so that bootstrap methods may be (and
often are) weakly typed whereas the bytecodes themselves are always
strongly typed.

To relax length restrictions on bootstrap specifiers, the language
which defines the invocation of bootstrap methods will be adjusted
(with complete backward compatibility) to allow variable arity
(ACC_VARARGS) bootstrap methods to absorb, into their trailing
arguments, all remaining static arguments, even if there are 2^16-1 of
them. (The classfile format already allows this, although there is no
way to read over-long bootstrap argument lists.) For consistency, the
invokeWithArguments methods of MethodHandle will also be expanded in
this way, if the target method has variable arity. In this way the
invocation of bootstrap methods can be specified in terms of the
weakly typed methods invokeWithArguments and invoke, just as today it
is specified in terms of invoke alone.



___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

the End of History in the constant pool

[John Rose]

(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  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