Valhalla EG minutes 6/21/17

[Karen Kinnear]

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 <paul.sandoz at oracle.com> 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 <karen.kinnear at oracle.com <mailto:karen.kinnear at oracle.com>> 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 <john.r.rose at oracle.com <mailto:john.r.rose at oracle.com>> wrote:
>>> 
>>> On Jul 5, 2017, at 11:39 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> 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
>> 
>