On Jun 25, 2017, at 12:47 PM, Mark Roos <mr...@roos.com> 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

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

Reply via email to