Re: constant-dynamic specification, updated

[Remi Forax]

> De: "John Rose" <john.r.r...@oracle.com>
> À: "Per Bothner" <p...@bothner.com>
> Cc: "Da Vinci Machine Project" <mlvm-dev@openjdk.java.net>
> Envoyé: Lundi 26 Juin 2017 00:21:58
> Objet: Re: constant-dynamic specification, updated

> On Jun 25, 2017, at 3:00 PM, Per Bothner < p...@bothner.com > wrote:

>> That will be difficult as long as constant pool indexes and various
>> other fields are limited to 16 bits.

> Yep; that's a challenge, until we break the glass and make a
> completely new class file format that integrates a var-int format.
> (My favorite is UNSIGNED5.)

> But we can (and should) put off the day of glass-breaking
> by tactical moves like CONSTANT_Group, which will allow
> you to express a single sequence of constant tokens of
> any length, without (necessarily) using up indexes in the
> main CP.

like an array of value types for the constant pool ! 

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

Re: constant-dynamic specification, updated

[John Rose]

On Jun 25, 2017, at 3:00 PM, Per Bothner  wrote:
> 
> That will be difficult as long as constant pool indexes and various
> other fields are limited to 16 bits.

Yep; that's a challenge, until we break the glass and make a
completely new class file format that integrates a var-int format.
(My favorite is UNSIGNED5.)

But we can (and should) put off the day of glass-breaking
by tactical moves like CONSTANT_Group, which will allow
you to express a single sequence of constant tokens of
any length, without (necessarily) using up indexes in the
main CP.

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

Re: constant-dynamic specification, updated

[Per Bothner]

On 06/25/2017 02:34 PM, John Rose wrote:


My overall goal is to keep the classfile alive as an efficient
medium for more and more advanced language runtimes.


That will be difficult as long as constant pool indexes and various
other fields are limited to 16 bits.
--
--Per Bothner
p...@bothner.com   http://per.bothner.com/
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: constant-dynamic specification, updated

[John Rose]

On Jun 25, 2017, at 12:47 PM, Mark Roos  wrote:
> 
> I was looking for boot strap args to allow byte[] constants from the 
> constantPool. 
> 
> Is that planned? 

Yes; there are two more CP types planned:

1. CONSTANT_Data = arbitrary blob of octets
2. CONSTANT_Group = series of constant specifiers outside of main CP

That would seem to complete the CP story.  You can build constants
by calling BSMs that take a flexible mix of random data octets and
references to constants.  You can't mix them together seamlessly,
but you can at least put all of your octets in one bag (Data) and all
of your constant references in another (Group).

We could think to use the CP to nest additional class syntax inside a CP entry.
E.g., CONSTANT_ClassDeclaration which would carry the bytes of a class-file
structure, *except* the constant pool prelude itself.  That might be a natural
way to allow nest several classes into one classfile (the old MClass idea).

(Why not just use CONSTANT_Data?  Because a class file parser
often needs to recursively descend into all parts of a class file which
may contain indexes into the constant pool, or detect other relations
between subparts of the file.  An opaque Data block defeats this.)

But it seems more likely that we would use attributes as envelopes for
the nested structure.  CP entries work better if they are of limited size.
That's why we put part of the payload of CONSTANT_InvokeDynamic
into the BootstrapMethods attribute instead of directly in the CP.
So think in terms of a ClassDefinitions attribute with a series of
definitions; then if we need CONSTANT_ClassDeclaration, it just
carries a single index into the attribute.

The CONSTANT_Data guy probably will carry payload in a segmented
ConstantDataBlocks attribute, and the CONSTANT_Group guy will
probably carry payload in a ConstantGroups attribute.  The structure
of both attributes will probably allow random access to variably-sized
large blobs of data.  The CGs will allow cheap nesting, for things like
ASTs.

At least, that's how I'm thinking about it.  My overall goal is to keep
the classfile alive as an efficient medium for more and more advanced
language runtimes.

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

Re: Fwd: constant-dynamic specification, updated

[Mark Roos]

Thx John.

I was looking for boot strap args to
allow byte[] constants from the constantPool.

Is that planned?

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

Fwd: constant-dynamic specification, updated

[John Rose]

Date: June 24, 2017 at 4:52:04 PM PDT
To: valhalla-spec-expe...@openjdk.java.net

I have updated the javadoc API that is relevant to the proposed
JVM features for dynamic constants and more powerful bootstrap
methods.

http://cr.openjdk.java.net/~jrose/jvm/condy-jvms-2017-0620.html

Here is a rough draft of the corresponding JVMS changes:

http://cr.openjdk.java.net/~jrose/jvm/specdiff-condy-2017-0624.zip

Please enjoy and comment.

— John

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