Valhalla EG minutes 6/21/17

[Paul Sandoz]

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