From karen.kinnear at oracle.com Thu Aug 10 17:09:11 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 10 Aug 2017 13:09:11 -0400 Subject: Cancelled: Valhalla EG meeting Wednesday August 16 Message-ID: Dan Smith and I will both be out of town. I am cancelling the meeting on August 16th. Thank you to everyone for all the hard work to get the MVT JVMS spec in a place for early experimentation. We sent the announcement to the valhalla-dev alias yesterday that the repository has an mvt branch that is ready to try. Please try it and send us feedback on that alias as well. For our next meeting, August 30th: AI 1:All: review ConstantDynamic JVMS http://cr.openjdk.java.net/~jrose/jvm/condy-jvms-2017-0620.html AI 2: In addition, we will be exploring some potential changes to the nestmates JVMS, which we will send in an email before then and can discuss at the meeting. thanks, Karen p.s. here were ConstantDynamic JVMS questions from Lois Foltan and me from July 19th email John, Condy JVMS looks really good. Couple of small questions/comments: 1. 4.5 fields in 5.4.3.6 you have a much clearer description of the argument types could you either reference that or include the bullets here? (the syntax is not clear from the sentence structure) 2. instructions that can use condy The JVMS lists ldc/ldc_w I think you mentioned that a bootstrap method specifier could contain a condy CP reference Are there other places these can appear today? 3. We need to discuss redefineclasses and BootstrapMethod Attributes - Lois and I think we may already have an issue here with indy and condy could just make this more common - we may want to enhance the redefineclasses documentation restrictions on attributes The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance. These restrictions maybe be lifted in future versions. The class file bytes are not checked, verified and installed until after the transformations have been applied, if the resultant bytes are in error this method will throw an exception. thanks, Karen From daniel.smith at oracle.com Mon Aug 14 22:38:58 2017 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 14 Aug 2017 16:38:58 -0600 Subject: Nestmates spec update Message-ID: <1D027809-57BC-4DFE-9593-83F4CE31994A@oracle.com> At the August 3 meeting, we discussed revising the treatment of private method invocations, asking compilers to use 'invokevirtual' and 'invokeinterface' rather than 'invokespecial'. This allows us to leave 'invokespecial' untouched, rather than adding to its already-significant complexity. See here for a proposed specification: http://cr.openjdk.java.net/~dlsmith/private-access.html The 'invokevirtual' calls were already supported, but in order to invoke private interface methods, we needed to enhance 'invokeinterface'. I thought the best way to accomplish this is to unify the selection process for 'invokevirtual' and 'invokeinterface' into a single algorithm. This also addresses some outstanding bugs and enhancement requests, as noted. ?Dan From brian.goetz at oracle.com Mon Aug 21 19:13:57 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 21 Aug 2017 15:13:57 -0400 Subject: Nestmates spec update In-Reply-To: <1D027809-57BC-4DFE-9593-83F4CE31994A@oracle.com> References: <1D027809-57BC-4DFE-9593-83F4CE31994A@oracle.com> Message-ID: Somewhere we should state that "nests form a partition over classes". (That is, each class belongs to exactly one nest.) "same package" -> "same package, module, class loader, and protection domain"? On 8/14/2017 6:38 PM, Dan Smith wrote: > At the August 3 meeting, we discussed revising the treatment of private method invocations, asking compilers to use 'invokevirtual' and 'invokeinterface' rather than 'invokespecial'. This allows us to leave 'invokespecial' untouched, rather than adding to its already-significant complexity. > > See here for a proposed specification: > http://cr.openjdk.java.net/~dlsmith/private-access.html > > The 'invokevirtual' calls were already supported, but in order to invoke private interface methods, we needed to enhance 'invokeinterface'. I thought the best way to accomplish this is to unify the selection process for 'invokevirtual' and 'invokeinterface' into a single algorithm. This also addresses some outstanding bugs and enhancement requests, as noted. > > ?Dan From forax at univ-mlv.fr Mon Aug 28 19:31:06 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 28 Aug 2017 21:31:06 +0200 (CEST) Subject: MVT spec and getfield Message-ID: <904961333.407275.1503948666585.JavaMail.zimbra@u-pem.fr> I've found the sentence in section (6.5 getfield) "The value, which must be of the referenced type, is popped from the operand stack." ambiguous. While is understand the sentence, it's easy to read "the referenced type" as a type reference. What about: "The value, which must be of the referenced field type, is popped from the operand stack." also in the "Linking Exceptions" subsection, there is no sentence to allow a value capable class to access to the field of its corresponding value type, vwithfield has such wording and the Note at the end of the vwithfield description seem to imply that getfield should follow the same rule. Note that if getfield on a value type can not be done inside a value capable class, because a value type cn not have any code (yet), it means that there is no way to access to a private field of a value type. regards, R?mi From karen.kinnear at oracle.com Wed Aug 30 16:05:03 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 30 Aug 2017 12:05:03 -0400 Subject: New Meeting ID Aug 30 valhalla eg meeting Message-ID: https://oracle.zoom.us/j/709160765?pwd=q7WlYluINEc%3D Apologies for the confusion, Karen From karen.kinnear at oracle.com Thu Aug 31 20:36:12 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 31 Aug 2017 16:36:12 -0400 Subject: ConstantDynamic bootstrap specifier resolution In-Reply-To: <5DB8EBD6-BCFE-44A7-869C-ACFB6216767E@oracle.com> References: <5DB8EBD6-BCFE-44A7-869C-ACFB6216767E@oracle.com> Message-ID: <54E31B37-FB00-4A2D-BC5F-4C650E5F471D@oracle.com> I wanted to clarify my understanding of the context for sharing vs. re-resolving the bootstrap specifier. Remi, Bjorn and I were discussing this recently and I wanted to follow up with the relevant JVMS text: Proposed http://cr.openjdk.java.net/~jrose/jvm/condy-jvms-2017-0620.html 5.4.3.6 Bootstrap Specifier Resolution: (Note: When a bootstrap method is used to resolve a dynamic call site, it is invoked once per distinct call site. When a bootstrap method is used to resolve a dynamic constant, it is called only once perCONSTANT_ConstantDynamic_info structure in the constant pool, not once per instruction which may use this constant.) Next, as part of the continuing resolution of the call site JVMS 8/9: 6.5 invoke dynamic: The call site specifier is resolved (?5.4.3.6 ) for this specific dynamic call site to obtain a reference to a java.lang.invoke.MethodHandle instance that will serve as the bootstrap method, a reference to a java.lang.invoke.MethodType instance, and references to static arguments. 5.4.3 Resolution: Resolution of the symbolic reference of one occurrence of an invokedynamic instruction does not imply that the same symbolic reference is considered resolved for any other invokedynamic instruction. <>For all other instructions above, resolution of the symbolic reference of one occurrence of an instruction does imply that the same symbolic reference is considered resolved for any other non-invokedynamic instruction. <> (The above text implies that the concrete value determined by resolution for a specific invokedynamic instruction is a call site object bound to that specific invokedynamic instruction.) So today we re-resolve the callsite specifier for EACH BCI. I presume that an invoke dynamic that has a static argument which is a constant dynamic will use the shared resolved bootstrap specifier for that constant dynamic, just as other static arguments that reference constant pool entries such as String, MethodType, MethodHandle, Class use shared resolution based on constant-pool entry. thanks, Karen From john.r.rose at oracle.com Thu Aug 31 21:12:55 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 31 Aug 2017 14:12:55 -0700 Subject: ConstantDynamic bootstrap specifier resolution In-Reply-To: <54E31B37-FB00-4A2D-BC5F-4C650E5F471D@oracle.com> References: <5DB8EBD6-BCFE-44A7-869C-ACFB6216767E@oracle.com> <54E31B37-FB00-4A2D-BC5F-4C650E5F471D@oracle.com> Message-ID: <2BFBD9F5-68D9-4C0B-BBBA-EDE4AF5252B2@oracle.com> On Aug 31, 2017, at 1:36 PM, Karen Kinnear wrote: > > So today we re-resolve the callsite specifier for EACH BCI. Yes, for invokedynamic. In order to make this work we have to allocate a distinct CP cache cell for each individual indy instruction. This is done in the Rewriter, and uses all 4 of the operand fields of indy. (None of this is true for condy.) > I presume that an invoke dynamic that has a static argument which is a constant dynamic will use the shared > resolved bootstrap specifier for that constant dynamic, just as other static arguments that reference > constant pool entries such as String, MethodType, MethodHandle, Class use shared resolution based on constant-pool entry. Yes. That is a basic behavior of the CP. To do anything else would require explicit language in the spec. and special code in the JVM, as for indy. ? John From john.r.rose at oracle.com Thu Aug 31 22:08:32 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 31 Aug 2017 15:08:32 -0700 Subject: ConstantDynamic JVMS comments In-Reply-To: <5DB8EBD6-BCFE-44A7-869C-ACFB6216767E@oracle.com> References: <5DB8EBD6-BCFE-44A7-869C-ACFB6216767E@oracle.com> Message-ID: <604670E8-5DF0-45C1-9F7F-789B69CE0941@oracle.com> (Going back to a dropped response!) On Jul 19, 2017, at 8:48 AM, Karen Kinnear wrote: > > ...small questions/comments: > > 1. 4.5 fields > in 5.4.3.6 you have a much clearer description of the argument types > could you either reference that or include the bullets here? (the syntax is not clear from the sentence structure) The brevity of the diffs at that point reflects the small size of the change to the syntax of the BootstrapMethods attribute. There are three changes: 1. the attribute is used by condy as well as indy 2. the BSM is allowed to be a non-varargs of arity 2 3. it is still the case that anything you can "ldc" you can put into a static BSM argument Making 3 true requires adding an item to a laundry list of allowable constant pool types for static arguments. (It's a duplicate of the list of allowed types for "ldc", modulo the one slot vs. two slot distinction.) Point 2 is future work, which will not land in the first cut of condy. That is support for BootstrapCallInfo, which allows BSM arguments to be resolved under programmer control instead of eagerly. See https://bugs.openjdk.java.net/browse/JDK-8186210 (I have also pasted a summary at the end, FTR.) That whole section just shows spot-edits for 1/2/3 above. It's a diff patch to the existing spec. There's nothing else there other than the pre-existing stuff. The "@@" marker is a diff-hunk boundary whose placement is arbitrary. I wasn't clever or industrious enough to the diff hunk boundaries be logical. That's why Dan's spec. proposals read better: He hand-edits in the diffs. I'm experimenting with a more webrev-like presentation here. The downside is the confusing transitions you are seeing. The upside is less hand-work. > 2. instructions that can use condy > The JVMS lists ldc/ldc_w > I think you mentioned that a bootstrap method specifier could contain a condy CP reference > > Are there other places these can appear today? No, the spec. mentions only BSM arguments and ldc. Future use: I would like to put them into ConstantValue attributes also, on static final fields. This will let us express lazy constants in the JVM. The actual proposal is a new attribute, ConstantDynamicValue. Please see https://bugs.openjdk.java.net/browse/JDK-8186006 > > 3. We need to discuss redefineclasses and BootstrapMethod Attributes > - Lois and I think we may already have an issue here with indy and condy could just > make this more common > - we may want to enhance the redefineclasses documentation restrictions on attributes > > The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance. These restrictions maybe be lifted in future versions. The class file bytes are not checked, verified and installed until after the transformations have been applied, if the resultant bytes are in error this method will throw an exception. I think we touched on this in a recent con-call. The worst case risk with redefinitions is probably having an index into the BootstrapMethods attribute change its meaning, in a way that breaks the type correctness of an indy or a condy that uses it. I think this is a pre-existing condition. We currently preserve pre-existing indexes into the constant pool and into the BsMs attribute. If this changes, we will have to do more editing to maintain referential integrity. Another issue, with "pull mode" (BootstrapCallInfo, item 2 above) is that the lazy pulling of constants provided by BootstrapCallInfo has to be robust across class redefinitions. The BCI object is created by the JVM and equipped with some sort of internal "cookie" that lets it refer to a particular sequence of BSM arguments. (Currently this is a simple integer index, just like everything else.) If we allow redefinitions to change pre-existing indexes, then the referential integrity of the BCI will have to be maintained, probably by means of a JVM-managed handle. In my view, the cost is so large and the benefit so small, that we will never choose to support classfile redefinitions which change pre-existing indexes into the CP or BsMs table. (The benefit, AFAIKS, is to allow longer chains of redefinitions without running over the limit of 2*16-1 CP entries. This does not impress me as a worthy goal. The user can just restart the app. if the debugging session gets too long. This feature will never be bulletproof, so restarting the app. is always on the table. Also, we may have a trick or two up our sleeves to raise the 16-bit limit on CP indexes, which would remove objections to index preservation. I'd rather solve that problem first.) ? John Summary of the BootstrapCallInfo feature (copied from JDK-8186210): If the bootstrap method accepts two parameters, and it is *not* a variable-arity method handle, then the linkage information is presented to the bootstrap method by a API which allows it to *pull* the static arguments. This allows the bootstrap logic the ability to order the resolution of constants and catch linkage exceptions. For this mode of linkage, the bootstrap method is is invoked on just two values: * a `MethodHandles.Lookup`, a lookup object on the *caller class* (as in the "push" mode) * a `BootstrapCallInfo` object describing the linkage parameters of the dynamic call site or constant ## Java APIs `public interface BootstrapCallInfo extends ConstantGroup` An interface providing full static information about a particular call to a bootstrap method of an dynamic call site or dynamic constant. This information include the method itself, the associated name and type, and any associated static arguments. If a bootstrap method declares exactly two arguments, and is not of variable arity, then it is fed only two arguments by the JVM, the lookup object and an instance of `BootstrapCallInfo` which supplies the rest of the information about the call. The API for accessing the static arguments allows the bootstrap method to reorder the resolution (in the constant pool) of the static arguments, and to catch errors resulting from the resolution. This mode of evaluation pulls bootstrap parameters from the JVM under control of the bootstrap method, as opposed to the JVM pushing parameters to a bootstrap method by resolving them all before the bootstrap method is called. API Note: The lookup object is not included in this bundle of information, so as not to obscure the access control logic of the program. In cases where there are many thousands of parameters, it may be preferable to pull their resolved values, either singly or in batches, rather than wait until all of them have been resolved before a constant or call site can be used. Method Summary * `MethodHandle bootstrapMethod?()` Returns the bootstrap method for this call. * `String invocationName?()` Returns the method name or constant name for this call. * `T invocationType?()` Returns the method type or constant type for this call. * `static BootstrapCallInfo makeBootstrapCallInfo?(MethodHandle bsm, String name, T type, ConstantGroup constants)` Make a new bootstrap call descriptor with the given components. `public interface ConstantGroup` An ordered sequence of constants, some of which may not yet be present. This type is used by `BootstrapCallInfo` to represent the sequence of bootstrap arguments associated with a bootstrap method, without forcing their immediate resolution. If you use the simple `get` method, the constant will be resolved, if this has not already happened. An occasional side effect of resolution is a `LinkageError`, which happens if the system could not resolve the constant in question. In order to peek at a constant without necessarily resolving it, use the non-throwing `get` method. This method will never throw a resolution error. Instead, if the resolution would result in an error, or if the implementation elects not to attempt resolution at this point, then the method will return the user-supplied sentinel value. To iterate through the constants, resolving as you go, use the iterator provided on the `List`-typed view. If you supply a sentinel, resolution will be suppressed. Typically the constant is drawn from a constant pool entry in the virtual machine. Constant pool entries undergo a one-time state transition from unresolved to resolved, with a permanently recorded result. Usually that result is the desired constant value, but it may also be an error. In any case, the results displayed by a `ConstantGroup` are stable in the same way. If a query to a particular constant in a `ConstantGroup` throws an exception once, it will throw the same kind of exception forever after. If the query returns a constant value once, it will return the same value forever after. The only possible change in the status of a constant is from the unresolved to the resolved state, and that happens exactly once. A constant will never revert to an unlinked state. However, from the point of view of this interface, constants may appear to spontaneously resolve. This is so because constant pools are global structures shared across threads, and because prefetching of some constants may occur, there are no strong guarantees when the virtual machine may resolve constants. When choosing sentinel values, be aware that a constant pool which has `CONSTANT_ConstantDynamic` entries can contain potentially any representable value, and arbitrary implementations of `ConstantGroup` are also free to produce arbitrary values. This means some obvious choices for sentinel values, such as `null`, may sometimes fail to distinguish a resolved from an unresolved constant in the group. The most reliable sentinel is a privately created object, or perhaps the `ConstantGroup` itself. Method Summary * `default List asList?()` Create a view on this group as a `List` view. * `default List asList?(Object ifNotPresent)` Create a view on this group as a `List` view. * `default int copyConstants?(int start, int end, Object[] buf, int pos)` Copy a sequence of constant values into a given buffer. * `default int copyConstants?(int start, int end, Object[] buf, int pos, Object ifNotPresent)` Copy a sequence of constant values into a given buffer. * `Object get?(int index)` Returns the selected constant, resolving it if necessary. * `Object get?(int index, Object ifNotPresent)` Returns the selected constant, or the given sentinel value if there is none available. * `boolean isPresent?(int index)` Returns an indication of whether a constant may be available. * `static ConstantGroup makeConstantGroup?(List constants, Object ifNotPresent, IntFunction constantProvider)` Make a new constant group with the given elements. * `int size?()` Returns the number of constants in this group. * `default ConstantGroup subGroup?(int start, int end)` Create a view on a sub-sequence of this group. Source files: http://hg.openjdk.java.net/amber/amber/jdk/file/2744935cd215/src/java.base/share/classes/java/lang/invoke/package-info.java#l124 http://hg.openjdk.java.net/amber/amber/jdk/file/2744935cd215/src/java.base/share/classes/java/lang/invoke/BootstrapCallInfo.java#l63 http://hg.openjdk.java.net/amber/amber/jdk/file/2744935cd215/src/java.base/share/classes/java/lang/invoke/ConstantGroup.java#l96