Valhalla EG Minutes 20200226

Attendees: Fred, Remi, Simms, John, Brian, Dan S, Dan H, Tobi - Brian: bring up the string vs trees - John: we were talking about that in a previous meeting, TLDR: want to avoid the premature optimizations - John: don't want to get caught up in naming things that can't be named - DanH: so to

Valhalla EG minutes June 05, 2019

Attendees: Remi, Tobi, Dan H, Karen AI: Remi - a request for a specific use case for indy with expression mode BSM if you could I. Valhalla Generics Remi: Are there any intermediate steps between LW10 Erased Generics and LW100 Specialized Generics? e.g Can we get reification without

Valhalla EG minutes May 22, 2019

Attendees: Remi, Tobi, Dan H, John, David Simms, Frederic, Karen I. Remi: the new static ()this needs to work with indy, but today you can’t use “<>” in the name. John: the MethodHandle is legit Dan H: name in a BSM does not have to relate to the underling method Remi: BSM has to change so

Valhalla EG minutes March 13, 2019

Attendees: Dan H, Tobi, Remi, Brian, Simms, Frederic, Karen corrections welcome (apologies for delay) I. Value Types user model Brian: Value types user model: V, V? (V? value set including null) replace .val and .box Don’t need all degrees of freedom. This is a simpler story, will capture in a

Valhalla EG minutes June 6, 2018

Attendees: Remi, Tobi, Dan H, Dan S, Frederic, Karen Corrections welcome. AIs: 1. Karen: proposal for value types consistency checking 2. Karen: updated proposal for handling statics No nestmate or condy topics. Value types: 1. ValueTypes attribute Remi: need to ensure that constant pool

Valhalla EG minutes

attendees: Tobi, Dan S, Simms, Frederic, Karen corrections welcome. 1. JVMLS talks LWorld - Tobi & Simms Condy - Dan H & Paul Sandoz Nestmates - Just a Small Change -> actual impact: Karen LWorld discussion - multiple folks willing to participate if this is wanted Abstracts (were) due May 25.

Re: Valhalla EG minutes May 9 and Apr 25 2018

JVMLS upcoming talks: Any interest in cohosting: 1) LWorld 2) Nestmates and the Alternate Accessors 3) VT workshop 4) Condy From my perspective, I'm interested in having the NM/Alternate Accessors talk, not because its "hot" news, but because it illustrates the real impact of

Valhalla EG minutes May 9 and Apr 25 2018

Corrections welcome - apologies for the delay May 9, 2018 Attendees: Remi, Dan H, ]Dan Smith, Frederic, David Simms, Karen JVMLS upcoming talks: Any interest in cohosting: 1) LWorld 2) Nestmates and the Alternate Accessors 3) VT workshop 4) Condy Nestmates: Plan is to get this into JDK 11 JEP

Re: Valhalla EG minutes Feb 14, 2018

> On Feb 20, 2018, at 7:52 AM, Karen Kinnear wrote: > > attendees: Tobi, Mr Simms, Dan H, Dan S, Frederic, Remi, Karen > > I. Condy > > 1. Condy reference implementation was pushed last week into JDK 11. > A next round of development will focus on the

Re: Valhalla EG minutes Jan 31, 3018

A clarification below: > On Feb 13, 2018, at 6:26 PM, Karen Kinnear wrote: > > attendees: Tobi, Dan Smith, Dan Heidinga, Karen Kinnear > > AIs: > Dan S: Condy SOE circularity issue: > - sent >

Valhalla EG minutes Dec 20, 2017

Happy New Year! Attendees: Remi, Dan H, Tobi, Dan S, John, Karen AIs: All - review nestmates JVMS invokeinterface selection changes All - review Dan’s proposal for constant pool structural descriptors Remi - proposal for T-Types - simpler approach to generic specialization I. Nestmates 1.

Valhalla EG minutes Dec 6 2017

Reminder - we will have our usual meeting Wednesday Dec 20. attendees: Remi, Tobi, Dan H, Mr Simms, Lois, Frederic, Dan S, John, Karen Corrections/clarification welcome I. Condy - targeted for JDK 18.9/jdk 11 for current JVMS version - note: next phase of Condy - with lazy resolution for

Valhalla EG minutes Nov 22

Attendees: Remi, Tobi, Dan H, Ron, Frederic, John, Karen Welcome Tobi Ajila from IBM! AIs: Nestmates overriding review - Graham and Dan H Reflection API review for nestmates - email thread: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-November/000411.html

Valhalla EG minutes Nov 8 2017

attendees: Remi, Dan H, John, Frederic, Lois, Mr Simms, Karen AI: Dan H/Karen - meet offline to discuss expected behavior today due to JVMS overriding rules AI: all - feedback on Nestmate Reflection API email thread I. Nestmates specifications 1. JVMS overriding rule checking: - Dan H

Re: Valhalla EG minutes October 25, 2017

Thank you for the clarification - I had misunderstood that. So if you ask for access and return false, with an error due to resolution - you just re throw the resolution failure. If there was no resolution error, then IllegalAccessError is returned with no cause. thank you! Karen > On Nov 1,

Re: Valhalla EG minutes October 25, 2017

On 2/11/2017 1:01 AM, Karen Kinnear wrote: IV Nestmates: summary of spec issues: 1. Reflection APIs - being discussed in an email with David Holmes 2. additional exception information - David Holmes proposed adding a cause to IllegalAccessError, e.g. as a way to report class not found or

Re: Valhalla EG minutes October 25, 2017

> On Nov 1, 2017, at 9:01 AM, Karen Kinnear wrote: > > 3. Dan S - respond to concerns below > 1. Issue - why do we have to rename Constant_InvokeDynamic to > Constant_DynamicCallSite? > Remi brought up a serious concern here > > Summary: there are three levels of

Valhalla EG minutes October 25, 2017

Attendees: Remi, Dan H, John, Mr Simms, Frederic, Lois, Karen AIs: 1. All - review updated ConDy spec 2. Dan H, Dan S - review Karen’s summary of transitive overriding implementation - once we agree on that, we can sanity check if the specification update matches (the intention was not to

Valhalla EG minutes Sept 27

Next Meeting Wednesday October 11 9am PT/ noon ET/… AI: Dan Smith - update of Condy JVMS changes - without BootstrapCallInfo AI: John - email of what is coming - including constant bits, constantGroup (and why more than BsCI provides) AI: All - nestmate JVMS feedback for Dan S attendees: Remi,

Re: Valhalla EG minutes Aug 30

takes the class as argument) Rémi - Mail original - > De: "Karen Kinnear" <karen.kinn...@oracle.com> > À: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Lundi 11 Septembre 2017 18:05:05 > Objet: Valhalla EG minutes Aug 3

Valhalla EG minutes Aug 30

Reminder, next meeting Wednesday Sept 13, 9am PT/noon ET/ new dial-in: https://oracle.zoom.us/j/5249803466 AI: All - review feedback on JVMS for nestmates for meeting on September 13th AI: Dan/Bjorn - do some experimentation with condy and give feedback on condy JVMS AI: All - nestmates

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

ily derive derived value class on touch)   It's not a requirement that the value class derivation is lazy, correct?       - Original message -From: Karen Kinnear <karen.kinn...@oracle.com>Sent by: "valhalla-spec-experts" <valhalla-spec-experts-boun...@openjdk.java.net

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