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