From karen.kinnear at oracle.com Wed Jul 5 13:07:06 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 5 Jul 2017 09:07:06 -0400 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: <4bce389e-3342-bcfa-0174-140ef4313134@cs.oswego.edu> References: <4bce389e-3342-bcfa-0174-140ef4313134@cs.oswego.edu> Message-ID: Doug, Thank you. I suspect we will dance together on specific performance improvements - so getting your use cases may identify optimizations we have not yet done - and that would be helpful to both of us. Ian - any feedback? thanks, Karen > On Jun 25, 2017, at 6:08 PM, Doug Lea

wrote: > > > I missed this meeting (out at PLDI/ISMM/ECOOP) but ... > > On 06/23/2017 04:33 PM, Karen Kinnear wrote: >> >> Hotspot and IBM: >> what could be available for early access for early adopters to >> experiment with? >> revisit early access timing - if we were to set expectations that >> - model would be to deliver binaries and periodic binary updates to >> match the source builds. This is not a one shot delivery. >> - limit functionality (platforms, reflection behavior unspecified, >> no JVMTI, ?) >> - performance improvements are not yet there, expect to come in >> incrementally >> - maybe verifier isn?t ready? >> - stability issues >> >> *Potential early adopters: Ian Graves? Doug Lea? Others?* >> * So - would you be willing to start experimenting with minimal value >> types even with the restrictions above?* >> > > Yes. This should be enough to try out some useful experiments. > At least if "not there yet" doesn't mean "dreadful" performance. > For example, trying out techniques for parallel sorting of values > seems possible, and is likely to be informative about other possible > concurrent/parallel library improvements. > > -Doug > > > > From karen.kinnear at oracle.com Wed Jul 5 14:12:30 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 5 Jul 2017 10:12:30 -0400 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: References:

Message-ID: <5DD65F4B-9996-42F8-A09A-EC454F128515@oracle.com> Bjorn, Thank you for the corrections. > On Jul 5, 2017, at 5:10 AM, Bjorn B Vardal wrote: > > > 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 rather than as an escape character (feel free to correct my notes) > > I meant to say the opposite of that: Since our DVT and VCC have the same name (because they rely on the same class data structure), > we would simply treat ";Q" as an escape character that switches to DVT mode, instead of as part of the name of the value class. That makes more sense. > > > > Bjorn: could hack using the different name as two views of the same thing > > e.g. vbox/vunbox would need to swap names > > (ed. note - please let us know if this is doable without heroic efforts) > > I can make this work as long as there's a predictable prefix and suffix, so ";Q$value" works. Thank you - very much appreciated. > > > > 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 see VCC - lazily derive derived value class on touch) > > It's not a requirement that the value class derivation is lazy, correct? Let?s double-check with Dan Smith at today?s meeting. The way I read 5.3 Creation and Loading in http://cr.openjdk.java.net/~dlsmith/values.html it appears to allow lazy derivation as well as eager derivation, which I think is what we both want since it allows implementations to optimize. Our current derivation is also eager. thanks, Karen > > > > ----- Original message ----- > From: Karen Kinnear > Sent by: "valhalla-spec-experts" > To: valhalla-spec-experts at openjdk.java.net > Cc: > Subject: Valhalla EG minutes 6/21/17 > Date: Fri, Jun 23, 2017 10:33 PM > > 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 can deliver early binaries for early adopters to try > > incremental proposals for post early access (or maybe post - MVT TBD) > Direct Value Class: Specification for Value Classes with Explicit Declarations: http://cr.openjdk.java.net/~dlsmith/values-declaration.html > Specification for Value Classes with CONSTANT_ClassType: http://cr.openjdk.java.net/~dlsmith/values-classtype.html#values-classtype-4.1 > All: review John Rose?s proposals: > ConstantDynamic JVMS changes: http://cr.openjdk.java.net/~jrose/jvm/condy-jvms-2017-0620.html > note: this is orthogonal to MVT > java/lang/Class.java makeSecondaryClass: http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2017-June/000286.html > post EA > > Hotspot and IBM: > what could be available for early access for early adopters to experiment with? > revisit early access timing - if we were to set expectations that > - model would be to deliver binaries and periodic binary updates to match the source builds. This is not a one shot delivery. > - limit functionality (platforms, reflection behavior unspecified, no JVMTI, ?) > - performance improvements are not yet there, expect to come in incrementally > - maybe verifier isn?t ready? > - stability issues > > Potential early adopters: Ian Graves? Doug Lea? Others? > So - would you be willing to start experimenting with minimal value types even with the restrictions above? > > We would find it helpful to get your feedback on > - the basic conceptual model > - usage model > - use cases - so we can optimize what you care about > - required features we missed > - so that when we ship this experimentally it is much closer to what you need > > Model of usage: > 1) Value-capable-class: created in java with annotation, javac generates a regular classfile with no new constant pool entries > or bytecodes > 2) MethodHandles and ValueType APIs > - this is the default model of usage > 3) generated byte codes > - you can generate your own byte codes to work on value types > - at this point you can?t generate your own value type class this way (until we get to Direct Value Class support) > > Constant Pool changes for Early Access: > 1) proposal for a value class is: > part I: CONSTANT_Class_info: UTF8: ?;Q;? // i.e. this would be a descriptor using a UTF8 string to speed up implementation > part II: hotspot requests that we use a different name for the value type than for the value capable class > implementation request - today we need unique strings to identify unique runtime types and this is baked in multiple places > > So propose: CONSTANT_Class_info: UTF8:?QFoo$ > > Where is the name exposed? > in the constant pool when you generate your own bytecodes - in descriptors and class names > > Dan S: Longer term: will declare a value class directly. The box first is a temporary approach in which we derive the value class. > Propose we not spend a lot of time here blurring the difference and needing to hide the derived value class. > > Bjorn: single representation for both value capable class and derived value class > I think you said ?treat ;Q? as the name for the derived value class rather than as an escape character (feel free to correct my notes) > > Dan S. Longer term: we do want one declaration and two views based on the value class. > > John: prefers Bjorn?s approach > > Bjorn: could hack using the different name as two views of the same thing > e.g. vbox/vunbox would need to swap names > (ed. note - please let us know if this is doable without heroic efforts) > > John: for hotspot - part of condy refactoring did part of the loaded class cache lookup changes that could be used here. > > 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 see VCC - lazily derive derived value class on touch) > > ---- > > John sent out a proposed API for a secondary mirror (see email link above) > note: not for EA > > Dan H: if ask for the same name for the secondary mirror what happens? > John: only libraries can use the proposed API and library is responsible for interning the name - not the VM. > > Remi: need ?nest? automatically for secondary mirror > John: yes eventually > Karen: not EA - need to check if time during MVT > > Remi: dynamic language implementor will want the same name - e.g. to get to shared static methods > today - because you can?t re-open a class folks generate ancillary classes to add static methods later > note: for printing purposes it would be helpful to have a different way to represent the name > > John: model on primitive type vs. wrapper type > > VWithfield - propose for MVT - allow package private access - since there are no methods on the derived value class > and the value capable class can?t have any methods with vbytecodes since generated by javac > - plan to make private when we add factory methods to value classes with a compiler (and we have nest support) > > Discussion of work needed to get to early access from various parties. See question above for early adopters > on potential restrictions to get this to you sooner. > > Teams need to re-assess timing assuming we want to make this available before we cross all the t?s and dot the i?s > (you just have to recognize this goes against the grain for any virtual machine engineer), but we do appreciate > that our first adopters would like to get this this summer while they have time to experiment and have shown > lots of willingness to work with us) > > Good news is: With the current JVMS (let?s get that reviewed and stamped), Remi is looking at modifying > ASM so folks will find it easier to generate byte codes. Many thanks! > > ASM needs: > 1) new opcodes and overloaded opcodes > 2) descriptor support > > note: this is independent of condy > > Maurizio - we would like to use that ASM internally whenever it is ready - that would make the MethodHandle API > able to take advantage of existing optimizations for references that we haven?t done yet > > So - goal is to have a binary snapshot available ASAP. > > Maurizio suggested we look at the JVMLS workshop time separately - need to discuss that next meeting. > > ?? > > Exposure of java/lang/__Value? > > Hotspot uses this today internally for MethodHandle LambdaForms - generating e.g. vreturn for __Value > (which is derived value class top type) . This is internal implementation magic - we pretend this is a marker class. > > Note: instanceof and checkcast do NOT work with value types in MVT. > > John: Longer-term: exploring QObject equivalent and a UObject which is at least a reference or value type > When we support interfaces and generics for value types we will need a user story users can trust > > Concern: ASM verification > John proposed: use invokeBasic model - wormhole from untyped to typed which is ignored by the verifier > > thanks, > Karen > > > > > > > > > > From karen.kinnear at oracle.com Wed Jul 5 14:26:03 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 5 Jul 2017 10:26:03 -0400 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: <7CD0F59D-4376-4340-98A4-ED186630E114@oracle.com> References: <7CD0F59D-4376-4340-98A4-ED186630E114@oracle.com> Message-ID: <42DD22F1-7095-4C21-8308-D0FEB3E8E56E@oracle.com> 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. Did I misunderstand what you were saying? thanks, Karen > On Jun 26, 2017, at 2:52 PM, Paul Sandoz wrote: > > >> On 23 Jun 2017, at 13:33, Karen Kinnear wrote: > >> VWithfield - propose for MVT - allow package private access - since there are no methods on the derived value class >> and the value capable class can?t have any methods with vbytecodes since generated by javac >> - plan to make private when we add factory methods to value classes with a compiler (and we have nest support) >> > > I am unsure if it?s necessary for MVT purposes to dial back the accessibility then dial it up again later on. > > ValueType.findWither can be used in conjunction with MethodHandle.privateLookupIn. It?s a little odd but works. What am i missing? > > Paul. > > > > From john.r.rose at oracle.com Wed Jul 5 16:11:51 2017 From: john.r.rose at oracle.com (John Rose) Date: Wed, 5 Jul 2017 09:11:51 -0700 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: <42DD22F1-7095-4C21-8308-D0FEB3E8E56E@oracle.com> References: <7CD0F59D-4376-4340-98A4-ED186630E114@oracle.com> <42DD22F1-7095-4C21-8308-D0FEB3E8E56E@oracle.com> Message-ID: 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 that nestmates can use that bytecode also. Access rules are as if it were a private method. We don't want to require bridge methods to use withers within a compilation unit. From paul.sandoz at oracle.com Wed Jul 5 16:28:22 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 5 Jul 2017 09:28:22 -0700 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: <42DD22F1-7095-4C21-8308-D0FEB3E8E56E@oracle.com> References: <7CD0F59D-4376-4340-98A4-ED186630E114@oracle.com> <42DD22F1-7095-4C21-8308-D0FEB3E8E56E@oracle.com> Message-ID: > On 5 Jul 2017, at 07:26, Karen Kinnear wrote: > > 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. > > Did I misunderstand what you were saying? > No, i was missing aspect that you were referring to byte code generation. What if we added a safe replacement for: Unsafe.defineAnonymousClass https://bugs.openjdk.java.net/browse/JDK-8171335 (Which we anyway have to do.) ? Then the VCC or DVT could be used as the host class. However, i dunno if that would be sufficient to cover the use-cases of byte code generation. Paul. > thanks, > Karen > >> On Jun 26, 2017, at 2:52 PM, Paul Sandoz wrote: >> >> >>> On 23 Jun 2017, at 13:33, Karen Kinnear wrote: >> >>> VWithfield - propose for MVT - allow package private access - since there are no methods on the derived value class >>> and the value capable class can?t have any methods with vbytecodes since generated by javac >>> - plan to make private when we add factory methods to value classes with a compiler (and we have nest support) >>> >> >> I am unsure if it?s necessary for MVT purposes to dial back the accessibility then dial it up again later on. >> >> ValueType.findWither can be used in conjunction with MethodHandle.privateLookupIn. It?s a little odd but works. What am i missing? >> >> Paul. >> >> >> >> > From karen.kinnear at oracle.com Wed Jul 5 17:48:15 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 5 Jul 2017 13:48:15 -0400 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: References: <7CD0F59D-4376-4340-98A4-ED186630E114@oracle.com> <42DD22F1-7095-4C21-8308-D0FEB3E8E56E@oracle.com> Message-ID: <668B9D76-47BA-4DD7-8BA8-3305E172F639@oracle.com> 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 than nest mates. We should re-evaluate adding a nest mate dependency when we get closer to deadlines and see if that works for our partners and our own timing. thanks, Karen > On Jul 5, 2017, at 12:28 PM, Paul Sandoz wrote: > > >> On 5 Jul 2017, at 07:26, Karen Kinnear wrote: >> >> 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. >> >> Did I misunderstand what you were saying? >> > > No, i was missing aspect that you were referring to byte code generation. > > What if we added a safe replacement for: > > Unsafe.defineAnonymousClass > https://bugs.openjdk.java.net/browse/JDK-8171335 > > (Which we anyway have to do.) > > ? > > Then the VCC or DVT could be used as the host class. However, i dunno if that would be sufficient to cover the use-cases of byte code generation. > > Paul. > >> thanks, >> Karen >> >>> On Jun 26, 2017, at 2:52 PM, Paul Sandoz wrote: >>> >>> >>>> On 23 Jun 2017, at 13:33, Karen Kinnear wrote: >>> >>>> VWithfield - propose for MVT - allow package private access - since there are no methods on the derived value class >>>> and the value capable class can?t have any methods with vbytecodes since generated by javac >>>> - plan to make private when we add factory methods to value classes with a compiler (and we have nest support) >>>> >>> >>> I am unsure if it?s necessary for MVT purposes to dial back the accessibility then dial it up again later on. >>> >>> ValueType.findWither can be used in conjunction with MethodHandle.privateLookupIn. It?s a little odd but works. What am i missing? >>> >>> Paul. >>> >>> >>> >>> >> > From paul.sandoz at oracle.com Wed Jul 5 17:59:29 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 5 Jul 2017 10:59:29 -0700 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: <668B9D76-47BA-4DD7-8BA8-3305E172F639@oracle.com> References: <7CD0F59D-4376-4340-98A4-ED186630E114@oracle.com> <42DD22F1-7095-4C21-8308-D0FEB3E8E56E@oracle.com> <668B9D76-47BA-4DD7-8BA8-3305E172F639@oracle.com> Message-ID: I strongly suspect we can specify a safe version of Unsafe.defineAnonymousClass (minus constant pool patching) independent of nest mates. I believe that is desirable on it?s own as part of the replace unsafe functionality and if that can help MVT then even better! Paul. > On 5 Jul 2017, at 10:48, Karen Kinnear wrote: > > 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 than nest mates. > We should re-evaluate adding a nest mate dependency when we get closer to deadlines and > see if that works for our partners and our own timing. > > thanks, > Karen > >> On Jul 5, 2017, at 12:28 PM, Paul Sandoz wrote: >> >> >>> On 5 Jul 2017, at 07:26, Karen Kinnear wrote: >>> >>> 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. >>> >>> Did I misunderstand what you were saying? >>> >> >> No, i was missing aspect that you were referring to byte code generation. >> >> What if we added a safe replacement for: >> >> Unsafe.defineAnonymousClass >> https://bugs.openjdk.java.net/browse/JDK-8171335 >> >> (Which we anyway have to do.) >> >> ? > >> >> Then the VCC or DVT could be used as the host class. However, i dunno if that would be sufficient to cover the use-cases of byte code generation. > >> >> Paul. >> >>> thanks, >>> Karen >>> >>>> On Jun 26, 2017, at 2:52 PM, Paul Sandoz wrote: >>>> >>>> >>>>> On 23 Jun 2017, at 13:33, Karen Kinnear wrote: >>>> >>>>> VWithfield - propose for MVT - allow package private access - since there are no methods on the derived value class >>>>> and the value capable class can?t have any methods with vbytecodes since generated by javac >>>>> - plan to make private when we add factory methods to value classes with a compiler (and we have nest support) >>>>> >>>> >>>> I am unsure if it?s necessary for MVT purposes to dial back the accessibility then dial it up again later on. >>>> >>>> ValueType.findWither can be used in conjunction with MethodHandle.privateLookupIn. It?s a little odd but works. What am i missing? >>>> >>>> Paul. >>>> >>>> >>>> >>>> >>> >> > From john.r.rose at oracle.com Wed Jul 5 18:06:33 2017 From: john.r.rose at oracle.com (John Rose) Date: Wed, 5 Jul 2017 11:06:33 -0700 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: References: <7CD0F59D-4376-4340-98A4-ED186630E114@oracle.com> <42DD22F1-7095-4C21-8308-D0FEB3E8E56E@oracle.com> <668B9D76-47BA-4DD7-8BA8-3305E172F639@oracle.com> Message-ID: <49BE4B8E-114E-4FD6-8FD4-13D7B0665628@oracle.com> 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 patching) independent of nest mates. I believe that is desirable on it?s own as part of the replace unsafe functionality and if that can help MVT then even better! We have an API point already for this, with a pre-planned "hole" for the functionality you want. If the VCC says "L=MethodHandles.lookup().in(DVT.class)" the Lookup should retain the PRIVATE access mode. Then, L.defineClass(...) is specified to throw an exception when it sees the PRIVATE access mode, but what is supposed to happen in the future is that the newly defined class is inserted into the nest of the Lookup.lookupClass. In the very specific case of a DVT, it would be reasonable to allow the injection you want, Paul, without throwing the required exception. After all, the DVT's are going away, so there's no compatibility risk for future changes to the API. The challenge to provide this for general use is to specify what happens when the Lookup has PRIVATE access mode. The best way to spec. this (IMO) is as a forcible injection into the nest of the Lookup.lookupClass. That requires nestmates to be specified *first*, and *then* we can specify what it means to inject a new (dynamically defined) nestmate. ? John From paul.sandoz at oracle.com Wed Jul 5 18:39:03 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 5 Jul 2017 11:39:03 -0700 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: <49BE4B8E-114E-4FD6-8FD4-13D7B0665628@oracle.com> References: <7CD0F59D-4376-4340-98A4-ED186630E114@oracle.com> <42DD22F1-7095-4C21-8308-D0FEB3E8E56E@oracle.com> <668B9D76-47BA-4DD7-8BA8-3305E172F639@oracle.com> <49BE4B8E-114E-4FD6-8FD4-13D7B0665628@oracle.com> Message-ID: <9A5B252B-FE91-4028-B607-64A71E60DE6E@oracle.com> > 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 patching) independent of nest mates. I believe that is desirable on it?s own as part of the replace unsafe functionality and if that can help MVT then even better! > > We have an API point already for this, with a pre-planned "hole" for the functionality you want. > > If the VCC says "L=MethodHandles.lookup().in(DVT.class)" the Lookup should retain the PRIVATE access mode. > Yes. > Then, L.defineClass(...) is specified to throw an exception when it sees the PRIVATE access mode, Right, i was just looking at that, currently scoped for package access. > but what is supposed to happen in the future is that the newly defined class is inserted into the nest of the Lookup.lookupClass. > 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. Paul. > In the very specific case of a DVT, it would be reasonable to allow the injection you want, Paul, without throwing the required exception. After all, the DVT's are going away, so there's no compatibility risk for future changes to the API. > > The challenge to provide this for general use is to specify what happens when the Lookup has PRIVATE access mode. The best way to spec. this (IMO) is as a forcible injection into the nest of the Lookup.lookupClass. That requires nestmates to be specified *first*, and *then* we can specify what it means to inject a new (dynamically defined) nestmate. > > ? John From john.r.rose at oracle.com Wed Jul 5 18:43:51 2017 From: john.r.rose at oracle.com (John Rose) Date: Wed, 5 Jul 2017 11:43:51 -0700 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: <9A5B252B-FE91-4028-B607-64A71E60DE6E@oracle.com> References: <7CD0F59D-4376-4340-98A4-ED186630E114@oracle.com> <42DD22F1-7095-4C21-8308-D0FEB3E8E56E@oracle.com> <668B9D76-47BA-4DD7-8BA8-3305E172F639@oracle.com> <49BE4B8E-114E-4FD6-8FD4-13D7B0665628@oracle.com> <9A5B252B-FE91-4028-B607-64A71E60DE6E@oracle.com> Message-ID: <39C316D5-37BC-4396-A13C-7DBBEFBDD589@oracle.com> 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 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 From brian.goetz at oracle.com Wed Jul 5 18:57:40 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 5 Jul 2017 14:57:40 -0400 Subject: constant-dynamic specification, updated In-Reply-To: References: Message-ID: <4a909f99-6074-6977-77c3-85ea493c7783@oracle.com> This is very nice. One thing that readers will wonder (doesn't belong in JVMS, but belongs somewhere) is what suggested practice are for using invocation name / constant name. I don't see the name widely used in indy, but I could imagine it more widely used in condy, because constants often have names (like Pi.) For a BSM that effectively has a single String parameter, I think we'll get more compact classfiles if we use the name and a shared no-arg BootstrapMethods entry, but is that a good reason? For example, for a primitive-class bootstrap, would this be a good use of the name? I don't understand this sentence: "A bootstrap specifier gives a method or fielddescriptor,/TD/." On the API: - The type parameter T to BCI is "dangling", in that there is nothing to constrain it. However, IIUC, it can only be MethodType or Class. In an ideal world, T would be bounded by the common supertype of these two things (NominalConstantRepresentingMemberDescriptor). We generally advise against use of unconstrained tvars like this in APIs, since it provides only the illusion of type safety, though I understand why you went this way -- you can have a BSM Foo bsm(Lookup lookup, BootstrapCallInfo bci) { ... } and just proceed without casting, and it's both convenient and self-documenting. If we had a common supertype in the future, we'd not be able to add this as a bound in a binary-compatible manner, because invocationType()Object would be burned into client classfiles. So it's kind of a dead-end. In any case, I'd add a stronger note about the range of T here. THere's room to put javadoc on tvars with "@param "; you could say "Must be Class or MethodType." - In ConstantGroup, do you want to clarify that constants described by multiple CGs might be the same constant, and therefore might share the one-time transition to resolved? Readers could think that the one-transition lifecycle is a property of "entry #3 in CG at 234098", not the constant that CG at 234098 happens to refer to in slot 3. I'd like to see some guidance about what a constant is. Condy will happily serve up mutable objects in the guise of dynamic constants, and the VM will have no regrets. However, this is likely to lead to pain (or security issues) for the user. Some sort of guidance here would be good, perhaps in the package javadoc. Also, related: what sort of facilities might we want to provide for caching/interning of equivalent constants across classes? I could easily imagine a BSM wanting to preserve the invariant that any LDC with a given set of args from any class results in the same object. On 6/24/2017 7:52 PM, John Rose wrote: > I have updated the javadoc API that is relevant to the proposed > JVM features for dynamic constants and more powerful bootstrap > methods. > > http://cr.openjdk.java.net/~jrose/jvm/condy-jvms-2017-0620.html > > Here is a rough draft of the corresponding JVMS changes: > > http://cr.openjdk.java.net/~jrose/jvm/specdiff-condy-2017-0624.zip > > Please enjoy and comment. > > ? John From daniel.smith at oracle.com Wed Jul 5 19:13:22 2017 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 5 Jul 2017 13:13:22 -0600 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: <5DD65F4B-9996-42F8-A09A-EC454F128515@oracle.com> References:

<5DD65F4B-9996-42F8-A09A-EC454F128515@oracle.com> Message-ID: > 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 see VCC - lazily derive derived value class on touch) >> >> It's not a requirement that the value class derivation is lazy, correct? > Let?s double-check with Dan Smith at today?s meeting. > > The way I read 5.3 Creation and Loading in > http://cr.openjdk.java.net/~dlsmith/values.html > it appears to allow lazy derivation as well as eager derivation, which I think is what we both want > since it allows implementations to optimize. > Our current derivation is also eager. Summary of today's discussion, supplemented with some reflection on what I see as the requirements: - The specification shouldn't care when the class is derived (though it must occur, naturally, no later than resolution of "Foo$Value"); the specification *might* care when error checking occurs, because that's observable. - Current specification draft says error checking occurs when Foo$Value is loaded (5.3), and that "Class or interface creation is triggered by another class or interface D, which references C through its run-time constant pool." So, as a test case: if my program has no references to Foo$Value (direct or reflective), no VCC-related errors would occur. - We could redesign this so that the VCC properties are checked during loading/verification of Foo. I am concerned that, where Foo is version 54.0 and has attribute ValueCapableClass, this sort of error checking will violate the Java SE 10 spec. Elaborating: we're presenting values as an optional feature of Java SE 10. For a JVM that does not implement the optional feature, JVMS 10 says that a ValueCapableClass attribute on a version 54.0 class file will be ignored. JVMS 4.7.1: "any attribute not defined as part of the class file specification must not affect the semantics of the class file. Java Virtual Machine implementations are required to silently ignore attributes they do not recognize." My interpretation of our mission, in adding an optional feature, is to provide new capabilities while having no impact on existing behavior. We can do new things where JVMS 10 specifies an error; we can't generate new errors where JVMS 10 specifies none. - We could limit usage/interpretation of "ValueCapableClass" to 54.1 class files. Then eager error checks when loading Foo would be fine. But the ability to work with 54.0 ValueCapableClass class files is an important use case. - Actually, examining that use case more closely, we discussed how attributes are not the right tool at all. We want clients of MVT to be able to generate interesting programs using a vanilla Java SE 10 compiler. The best mechanism to communicate "I'm a value-capable class" using a vanilla Java compiler is annotations, not attributes. Tentatively, the spec should be revised so that: - The "ValueCapableClass" attribute no longer exists. Delete changes to 4.7 and delete new section 4.7.25. - A "value capable class" is a class whose RuntimeVisibleAnnotations includes a ValueCapableClass annotation (package TBD; whether the referenced class must be loaded TBD) - As usual, this annotation doesn't impact behavior of class Foo - When loading Foo$Value, as specified in 5.3, we'll check that Foo is a value capable class and that it has the right properties ?Dan From john.r.rose at oracle.com Wed Jul 5 19:51:18 2017 From: john.r.rose at oracle.com (John Rose) Date: Wed, 5 Jul 2017 12:51:18 -0700 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: References:

<5DD65F4B-9996-42F8-A09A-EC454F128515@oracle.com> Message-ID: <0EA0F802-333E-40F7-B344-3739C8082933@oracle.com> 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 than resolution of "Foo$Value"); the specification *might* care when error checking occurs, because that's observable. Even more specifically: "when errors are reported". Checking can happen long before reporting. > - Current specification draft says error checking occurs when Foo$Value is loaded (5.3), and that "Class or interface creation is triggered by another class or interface D, which references C through its run-time constant pool." So, as a test case: if my program has no references to Foo$Value (direct or reflective), no VCC-related errors would occur. I would prefer this in MVT, but it's not a showstopper. In the long term this might be a good move, relative to operations that resolve Q-Foo (not Foo$Value), if Foo is supposed to be "merely an object" until suddenly its value aspect comes into play. In the usual case where some ACC_VALUE bit is present in the class file, there is no cause to delay error processing. > - We could redesign this so that the VCC properties are checked during loading/verification of Foo. I am concerned that, where Foo is version 54.0 and has attribute ValueCapableClass, this sort of error checking will violate the Java SE 10 spec. > > Elaborating: we're presenting values as an optional feature of Java SE 10. For a JVM that does not implement the optional feature, JVMS 10 says that a ValueCapableClass attribute on a version 54.0 class file will be ignored. JVMS 4.7.1: "any attribute not defined as part of the class file specification must not affect the semantics of the class file. Java Virtual Machine implementations are required to silently ignore attributes they do not recognize." My interpretation of our mission, in adding an optional feature, is to provide new capabilities while having no impact on existing behavior. We can do new things where JVMS 10 specifies an error; we can't generate new errors where JVMS 10 specifies none. This is a good point. It's the right way to manage the spec. OTOH, it's hard to construct examples where this matters for MVT. If I forget to use a VM that supports DVTs (or forget to flip the On switch), I am practically certain to get an error if I run my example MVT code. The error should occur as soon as the DVT is extracted. But it might also occur if the JVM falls over (due to some bug) when it loads the VCC and asks itself a premature question. Practically speaking, I will never expect (in MVT) to use a VCC as a POJO with DVTs turned off. > > - We could limit usage/interpretation of "ValueCapableClass" to 54.1 class files. Then eager error checks when loading Foo would be fine. But the ability to work with 54.0 ValueCapableClass class files is an important use case. Confirmed. This is why "Shady" speaks of mainly of an annotation to enable VCCs. (Over-cautiously, it also says "perhaps an attribute".) I should have mentioned this earlier. > - Actually, examining that use case more closely, we discussed how attributes are not the right tool at all. We want clients of MVT to be able to generate interesting programs using a vanilla Java SE 10 compiler. The best mechanism to communicate "I'm a value-capable class" using a vanilla Java compiler is annotations, not attributes. > > Tentatively, the spec should be revised so that: > - The "ValueCapableClass" attribute no longer exists. Delete changes to 4.7 and delete new section 4.7.25. > - A "value capable class" is a class whose RuntimeVisibleAnnotations includes a ValueCapableClass annotation (package TBD; whether the referenced class must be loaded TBD) > - As usual, this annotation doesn't impact behavior of class Foo > - When loading Foo$Value, as specified in 5.3, we'll check that Foo is a value capable class and that it has the right properties Also: - The annotation is ignored if the VCC does not have permission to access the annotation. (It's filtered like @Contended, which is not in the spec.) This check is complex to implement in general, since it interacts with the bootstrapping of the module system runtime. But in fact it only needs to work for the specific @ValueCapableClass annotation. That means a hardwired check to is likely to work, by embedded into the JVM which modules have access to the @VCC annotation. For @Contended it works because the JVM "just knows" that @Contended lives in an unexported package of java.base. ? John From paul.sandoz at oracle.com Wed Jul 5 20:08:26 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 5 Jul 2017 13:08:26 -0700 Subject: constant-dynamic specification, updated In-Reply-To: <4a909f99-6074-6977-77c3-85ea493c7783@oracle.com> References: <4a909f99-6074-6977-77c3-85ea493c7783@oracle.com> Message-ID: <957B7AE8-9DFA-46D1-A065-AD94E4BE6612@oracle.com> > On 5 Jul 2017, at 11:57, Brian Goetz wrote: > > This is very nice. > > One thing that readers will wonder (doesn't belong in JVMS, but belongs somewhere) is what suggested practice are for using invocation name / constant name. I don't see the name widely used in indy, but I could imagine it more widely used in condy, because constants often have names (like Pi.) For a BSM that effectively has a single String parameter, I think we'll get more compact classfiles if we use the name and a shared no-arg BootstrapMethods entry, but is that a good reason? For example, for a primitive-class bootstrap, would this be a good use of the name? > That?s how it?s applied by javac and the BSM (j.l.i.DynamicConstants.primitiveClassBootstrap) in the amber branch. For a VarHandle to a field, the name corresponds to the field name (for an array it is redundant). (FWIW the StringConcatFactory BSM could of used the name for the recipe encoding. Arguably with condy a richer recipe description could be used as a BSM argument rather than encoding it all into a string.) > I don't understand this sentence: "A bootstrap specifier gives a method or field descriptor, TD." > > On the API: > > - The type parameter T to BCI is "dangling", in that there is nothing to constrain it. However, IIUC, it can only be MethodType or Class. In an ideal world, T would be bounded by the common supertype of these two things (NominalConstantRepresentingMemberDescriptor). We generally advise against use of unconstrained tvars like this in APIs, since it provides only the illusion of type safety, though I understand why you went this way -- you can have a BSM > > Foo bsm(Lookup lookup, BootstrapCallInfo bci) { ... } > > and just proceed without casting, and it's both convenient and self-documenting. > > If we had a common supertype in the future, we'd not be able to add this as a bound in a binary-compatible manner, because invocationType()Object would be burned into client classfiles. So it's kind of a dead-end. In any case, I'd add a stronger note about the range of T here. THere's room to put javadoc on tvars with "@param "; you could say "Must be Class or MethodType." > > - In ConstantGroup, do you want to clarify that constants described by multiple CGs might be the same constant, and therefore might share the one-time transition to resolved? Readers could think that the one-transition lifecycle is a property of "entry #3 in CG at 234098", not the constant that CG at 234098 happens to refer to in slot 3. > > > I'd like to see some guidance about what a constant is. Condy will happily serve up mutable objects in the guise of dynamic constants, and the VM will have no regrets. However, this is likely to lead to pain (or security issues) for the user. Some sort of guidance here would be good, perhaps in the package javadoc. > > Also, related: what sort of facilities might we want to provide for caching/interning of equivalent constants across classes? I could easily imagine a BSM wanting to preserve the invariant that any LDC with a given set of args from any class results in the same object. > And also that the constant returned from a condy might store a ConstantGroup for later resolution of further values, namely the scope of resolution can exceed that of the BSM invocation (which is what i suspect might happen for pattern matching). Paul. From paul.sandoz at oracle.com Thu Jul 6 20:02:39 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 6 Jul 2017 13:02:39 -0700 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: <39C316D5-37BC-4396-A13C-7DBBEFBDD589@oracle.com> References: <7CD0F59D-4376-4340-98A4-ED186630E114@oracle.com> <42DD22F1-7095-4C21-8308-D0FEB3E8E56E@oracle.com> <668B9D76-47BA-4DD7-8BA8-3305E172F639@oracle.com> <49BE4B8E-114E-4FD6-8FD4-13D7B0665628@oracle.com> <9A5B252B-FE91-4028-B607-64A71E60DE6E@oracle.com> <39C316D5-37BC-4396-A13C-7DBBEFBDD589@oracle.com> Message-ID: 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 defineClass(boolean isAnon, byte[] data, Object constant) That?s a little fuzzy since it?s not clear to me how the generated class locates the constant (synthetic static final field of known name? substitute the last entry in the CP if appropriately defined in the class bytes as substitutable?). Paul. > On 5 Jul 2017, at 11:43, John Rose wrote: > > 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 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 From forax at univ-mlv.fr Thu Jul 6 20:12:30 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 6 Jul 2017 22:12:30 +0200 (CEST) Subject: Valhalla EG minutes 6/21/17 In-Reply-To: References:

<668B9D76-47BA-4DD7-8BA8-3305E172F639@oracle.com> <49BE4B8E-114E-4FD6-8FD4-13D7B0665628@oracle.com> <9A5B252B-FE91-4028-B607-64A71E60DE6E@oracle.com> <39C316D5-37BC-4396-A13C-7DBBEFBDD589@oracle.com> Message-ID: <432349830.2490944.1499371950101.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > ?: "John Rose" > Cc: valhalla-spec-experts at openjdk.java.net > Envoy?: Jeudi 6 Juillet 2017 22:02:39 > Objet: 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 defineClass(boolean isAnon, byte[] data, Object constant) > > That?s a little fuzzy since it?s not clear to me how the generated class locates > the constant (synthetic static final field of known name? substitute the last > entry in the CP if appropriately defined in the class bytes as substitutable?). Lookup.getConstant() with a private Lookup ? > > Paul. R?mi > >> On 5 Jul 2017, at 11:43, John Rose wrote: >> >> 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 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 From john.r.rose at oracle.com Thu Jul 6 22:58:08 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 6 Jul 2017 15:58:08 -0700 Subject: Valhalla EG minutes 6/21/17 In-Reply-To: References: <7CD0F59D-4376-4340-98A4-ED186630E114@oracle.com> <42DD22F1-7095-4C21-8308-D0FEB3E8E56E@oracle.com> <668B9D76-47BA-4DD7-8BA8-3305E172F639@oracle.com> <49BE4B8E-114E-4FD6-8FD4-13D7B0665628@oracle.com> <9A5B252B-FE91-4028-B607-64A71E60DE6E@oracle.com> <39C316D5-37BC-4396-A13C-7DBBEFBDD589@oracle.com> Message-ID: 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 much? Sure, that's OK, or else an 'isAnonymous' optional argument. The difficult part here is specifying exactly what is a "host class". > That still leaves the possibility of another method in the future say: > > Class defineClass(boolean isAnon, byte[] data, Object constant) > > That?s a little fuzzy since it?s not clear to me how the generated class locates the constant (synthetic static final field of known name? substitute the last entry in the CP if appropriately defined in the class bytes as substitutable?). On Jul 6, 2017, at 1:12 PM, Remi Forax wrote: > > Lookup.getConstant() with a private Lookup ? Exactly, an ad hoc API point like that. Would fit nicely with a BSM and CONSTANT_ConstantDynamic and ldc. Or a private static final and code in . If you need several of them, a Map would be your friend. This doesn't need to be baked into the Lookup API, just a design pattern, supported nicely by a slightly different BSM. ? John From john.r.rose at oracle.com Thu Jul 6 23:34:48 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 6 Jul 2017 16:34:48 -0700 Subject: constant-dynamic specification, updated In-Reply-To: <4a909f99-6074-6977-77c3-85ea493c7783@oracle.com> References: <4a909f99-6074-6977-77c3-85ea493c7783@oracle.com> Message-ID: <2441BC64-0D14-453D-9AD0-26235F85C344@oracle.com> On Jul 5, 2017, at 11:57 AM, Brian Goetz wrote: > > This is very nice. > > One thing that readers will wonder (doesn't belong in JVMS, but belongs somewhere) is what suggested practice are for using invocation name / constant name. I don't see the name widely used in indy, but I could imagine it more widely used in condy, because constants often have names (like Pi.) For a BSM that effectively has a single String parameter, I think we'll get more compact classfiles if we use the name and a shared no-arg BootstrapMethods entry, but is that a good reason? Combined with one other reason it is good enough. The other reason is that invokedynamic BSMs already take a method name. It is helpful to keep indy and condy BSMs similar, where possible. The similarity allows similar parts to be factored together, in both spec. and implementation. The similarity, in brief, condy:indy :: Fieldref:Methodref. In all cases, you have a NameAndType (field or method) accompanied by either a Class or a BSM. > For example, for a primitive-class bootstrap, would this be a good use of the name? Here FTR are some use cases for constants with very simple names: - enums (all enums can use *one* BSM in common) - other ad hoc manifest constants (Math.PI; BSM must be told which class) - primitives (really, ad hoc access to "W.TYPE" constants, but "I" is more compact) - simple extended numerics ("2/3", "1i2") - dates, times ("12:30am") - any other naming system (encodings? locales? timezones? geos?) - format specifiers (like the 'recipe' of StringConcatFactory) The overall effect is to keep the length of the BootstrapMethods attribute small even if there are large numbers of simple constants floating around. (Also, Note that integer constants divide into small?aconst_2, bipush, sipush?and large?ldc CONSTANT_Integer. Similarly, small numerics might be well served by using name strings when they are short, and component-wise BSMs otherwise.) If indy had not already set the pattern, these (taken all together) are IMO barely enough to motivate allowing this extra-compact way of defining constants, but only after a close accounting of the exact number of CP and BSM indexes consumed by each proposed translation strategy. (I should say that indy set this pattern because of a similar analysis for method names. So the StringConcatFactory could use this trick to implement all concatenations with one BSM. The DynaLink API can make good use of the method names, allowing one BSM to serve all invocation instructions.) > I don't understand this sentence: "A bootstrap specifier gives a method or field descriptor, TD." The vague phrase "a foo specifier gives a bar" appears a lot. It could be super-explicit: "A bootstrap specifier gives a CONSTANT_Utf8 string which encodes a method descriptor or field descriptor; call it TD." Or: "A bootstrap specifier gives a method descriptor or a field descriptor; call it TD." > > On the API: > > - The type parameter T to BCI is "dangling", in that there is nothing to constrain it. However, IIUC, it can only be MethodType or Class. In an ideal world, T would be bounded by the common supertype of these two things (NominalConstantRepresentingMemberDescriptor). We generally advise against use of unconstrained tvars like this in APIs, since it provides only the illusion of type safety, though I understand why you went this way -- you can have a BSM > > Foo bsm(Lookup lookup, BootstrapCallInfo bci) { ... } > > and just proceed without casting, and it's both convenient and self-documenting. Yep. And I uses BootstrapCallInfo