I think we have been discussing two different time frames. For the MVT EA we won’t have nest mates, so there I was pushing back on the dependency and we will stick with the package private access.
Post-EA - I totally agree with going through a lookup mechanism, and I would like to design this around nest mates - and have the Lookup.defineClass(…) PRIVATE mode be an early use case of nest mates. Totally agree with trying to pull this one off. It would make sense for the VCC/DVT to be nest mates, the VCC would have to be the nest-top so it could be loaded with or without the DVT. ( Non-MVT I would expect the valhalla value class to be the nest-top.) For byte code generation uses - I assume you are generating additional methods that you would want to add to the nest. Are those temporary classes? And if I understand the proposal correctly, we are replacing constant pool patching with Lookup.getConstant() with a private Lookup, which uses an ldc of condy underneath, so essentially the BSM is filling in new types in the condy constant pool entries. hope this is clearer, thanks, Karen > On Jul 11, 2017, at 7:10 PM, Paul Sandoz <[email protected]> wrote: > > Hi Karen, > > Thanks, i understand the need for being conservative here in case we get > things wrong. The pragmatic relaxation is entirely reasonable, although i > would still prefer to go through a lookup mechanism if we could pull it off > :-) > > Paul. > >> On 11 Jul 2017, at 14:42, Karen Kinnear <[email protected] >> <mailto:[email protected]>> wrote: >> >> Paul, >> >> We are working hard on getting the nest mates requirements clarified. >> I would like to use that to support the Lookup.defineClass and not do a >> Quick&Dirty >> in advance for MVT . I think we should stick with the reduced restrictions >> for withfield for early access. I think we should put our energy into getting >> nest mates and Lookup.defineClass ready. >> >> We have three parts to Lookup.defineClass. >> 1) PRIVATE mode handling - which we believe we can support with nest mates >> - we do not want to do any versions of this based on unsafe.DAC current >> behavior, >> - we are looking at cleaner behavior for nestmates >> 2) “temporary” name - i.e. find doesn’t work >> 3) CP patching/user data >> >> My mental model is that we don’t have to add all of these at the same time, >> although we will want user feedback on when to remove >> unsafe.DefineAnonymousClass. >> In fact, we would love more examples of current use cases, to help guide our >> design. >> >> thanks, >> Karen >> >>> On Jul 5, 2017, at 2:43 PM, John Rose <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On Jul 5, 2017, at 11:39 AM, Paul Sandoz <[email protected] >>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> I was unsure if we require a new method L.defineAnonClass or could >>>> leverage the existing L.defineClass. IIUC for expediency the current hooks >>>> in the VM lean towards anon classes, since there is already code to defer >>>> to the host class, whereas the general defineClass case will likely >>>> require more work, although i can potentially see some short cuts if we >>>> focus on VCC/DVT. >>>> >>> >>> Good point. Yes, that part isn't designed yet. It may manifest as an >>> extra argument or two to the L.dC. >>> >>> At least two degrees of freedom apply there: 1. suppressing the name (no >>> system dictionary update), >>> 2. providing some sort of "user data" to bind to the class (can be a single >>> ref., replaces CP patching). >>> >>> For MVT we can just generate a throwaway name, like DVT.getName()+":29348". >>> >>> — John >> >
