Re: Valhalla EG minutes 6/21/17

On Jul 19, 2017, at 7:31 AM, Daniel Heidinga wrote: > > There are a couple of different terms that have been used to describe early > access features - incubator (jep 11), experiment, or optional. At least for > me, these different terms result in different mental

Re: Valhalla EG minutes 6/21/17

> De: "Daniel Heidinga" <daniel_heidi...@ca.ibm.com> > À: "daniel smith" <daniel.sm...@oracle.com> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Mercredi 19 Juillet 2017 16:31:18 > Objet: Re: Valha

off-list Re: Valhalla EG minutes 6/21/17

Hi, Off-list as i am not sure i wanna commit to this publicly :-) In the interest of moving this forward independent of MVT i can prototype some of this if you like and use the three usages of U.DAC in the JDK as use-cases (see also [1]) Perhaps surprisingly grepcode.com reports no external

Re: Valhalla EG minutes 6/21/17

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

Re: Valhalla EG minutes 6/21/17

> On 6 Jul 2017, at 15:58, John Rose wrote: > > On Jul 6, 2017, at 1:02 PM, Paul Sandoz > wrote: >> >> In terms of what we have today we could easily do: >> >> // lookup must have private access to the lookup

Re: Valhalla EG minutes 6/21/17

On Jul 6, 2017, at 1:02 PM, Paul Sandoz wrote: > > In terms of what we have today we could easily do: > > // lookup must have private access to the lookup class, which becomes the > “host” class > Class defineAnonymousClass(byte[] data) > > is that ending gaining too

Re: Valhalla EG minutes 6/21/17

- Mail original - > De: "Paul Sandoz" <paul.san...@oracle.com> > À: "John Rose" <john.r.r...@oracle.com> > Cc: valhalla-spec-experts@openjdk.java.net > Envoyé: Jeudi 6 Juillet 2017 22:02:39 > Objet: Re: Valhalla EG minutes 6/21/17 >

Re: Valhalla EG minutes 6/21/17

In terms of what we have today we could easily do: // lookup must have private access to the lookup class, which becomes the “host” class Class defineAnonymousClass(byte[] data) is that ending gaining too much? That still leaves the possibility of another method in the future say: Class

Re: Valhalla EG minutes 6/21/17

On Jul 5, 2017, at 12:13 PM, Dan Smith wrote: > Summary of today's discussion, supplemented with some reflection on what I > see as the requirements: Thanks! > - The specification shouldn't care when the class is derived (though it must > occur, naturally, no later

Re: Valhalla EG minutes 6/21/17

> On Jul 5, 2017, at 8:12 AM, Karen Kinnear wrote: > >> > Dan S: class loading in the proposed JVMS: if you see $Value >> >1) first derive the VCC name and see if already resolved >> >2) if not - load the VCC, check properties and derive >> >(ed. note - if

Re: Valhalla EG minutes 6/21/17

On Jul 5, 2017, at 11:39 AM, Paul Sandoz 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

Re: Valhalla EG minutes 6/21/17

> On 5 Jul 2017, at 11:06, John Rose wrote: > > On Jul 5, 2017, at 10:59 AM, Paul Sandoz > wrote: >> >> I strongly suspect we can specify a safe version of >> Unsafe.defineAnonymousClass (minus constant pool

Re: Valhalla EG minutes 6/21/17

Agree with John’s clarification - yes we are planning longterm for nest mate access. And your proposal of using a safe replacement for Unsafe.defineAnonymousClass with appropriate access to add into the nest makes sense. At this time we are building an Early Access that needs to go out sooner

Re: Valhalla EG minutes 6/21/17

On Jul 5, 2017, at 7:26 AM, Karen Kinnear wrote: > > John’s longer term plan is that ultimately the byte code can only be executed > in the value class itself Slight correction: ultimately the byte code requires private access to the value class itself. This means

Re: Valhalla EG minutes 6/21/17

Paul, What we were discussing was the ability to use the byte code itself - not the ValueType.findWither API. John’s longer term plan is that ultimately the byte code can only be executed in the value class itself, and since the derived value class has no methods, we need a temporary approach.

Re: Valhalla EG minutes 6/21/17

karen.kinn...@oracle.com> > Sent by: "valhalla-spec-experts" > <valhalla-spec-experts-boun...@openjdk.java.net> > To: valhalla-spec-experts@openjdk.java.net > Cc: > Subject: Valhalla EG minutes 6/21/17 > Date: Fri, Jun 23, 2017 10:33 PM > > attendees: Rem

Re: Valhalla EG minutes 6/21/17

> Bjorn: single representation for both value capable class and derived value class   We basically rely on single class data structure for the VCC and DVT, but we still expose these as separate java/lang/Class objects.     >     I think you said “treat ;Q” as the name for the derived value class

Valhalla EG minutes 6/21/17

attendees: Remi, Bjorn, Dan H, Dan S, John, Maurizio, Frederic, Lois, Karen AIs: All: review Dan Smith’s proposals MVT JVMS: Specification for Value Classes: http://cr.openjdk.java.net/~dlsmith/values.html - initial proposal *** let’s pin this down ASAP so we - Remi for ASM, IBM and Oracle