> On Jun 16, 2020, at 12:13 PM, Dan Smith <[email protected]> wrote: > > - "Evolving CONSTANT_Class": I described some design choices involving > constant pool encodings of types and classes. I'd love to make some progress > here, let's discuss.
Here's a brief summary of the discussion (I'll take better notes next time): - John described some ideas he's exploring in the design of specialization. The relevant point is that descriptors and Class constants may not need to express species types at all, leading to an approach where those things stay mostly unchanged, and new type information (maybe even 'Q' types?) is represented with new constants. - I asked some questions about the relative merits of approaches that enforce "new" types (e.g., for putfield) via i) static validation in the verifier; ii) dynamic checks at run time; or iii) tolerating pollution as a "slow path". - Dan H. expressed a preference for encodings that avoid overloading, particularly when it has the effect of checking flags and branching at run time. - Frederic had some concerns about putting things in the "class" bucket, rather than the "type" bucket, where there's useful information in the type. We talked about whether we like modeling fields/methods as members of classes or as members of types. - I talked about the distinction between resolution-optimized type encodings (CONSTANT_Class) and matching-optimized type encodings (Utf8 descriptors), arguing that it may make sense to preserve both styles as we evolve. My takeaway is that the requirements are in flux, so it's hard to draw firm conclusions right now, but that we are leaning towards something like CONSTANT_Type (#4 in my email) to be used where we need to resolve and dynamically act on "types" (checkcast, anewarray). (There may be a stronger distinction made between verification/descriptor types and "live", possibly client-specified, runtime types.)
