From forax at univ-mlv.fr  Fri Sep  1 22:39:42 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 2 Sep 2017 00:39:42 +0200 (CEST)
Subject: ConstantDynamic JVMS comments
In-Reply-To: <604670E8-5DF0-45C1-9F7F-789B69CE0941@oracle.com>
References: <5DB8EBD6-BCFE-44A7-869C-ACFB6216767E@oracle.com>
 <604670E8-5DF0-45C1-9F7F-789B69CE0941@oracle.com>
Message-ID: <971262036.2409354.1504305582779.JavaMail.zimbra@u-pem.fr>

Hi John, 

Thinking a little bit about that, 
1/ conceptually a BootstrapCallInfo and a ConstantGroup are every similar, it's a bunch of constants, the BootstrapCallInfo as just a special meaning for some of them. 
2/ at runtime, it's like an array or a java.util.List (again conceptually) of stable values which is lazily populated 

Bold claims: 
1/ we do not need both BootstrapCallInfo and ConstantGroup, only one is enough, 
yes it means that an indy of a condy BSM will have at least 4 parameters (lookup, name, type, constantgroup), 
constantgroup play the role of kind of array (a new kind of Array 2.0 ?) 
2/ ConstantGroup should only have two methods, size() and get(index) (and perhaps asList() for interropt), the fact that asking for a value will trigger an initialization or not should not be part of the spec. 
There is a good reason for that, an image format like CDS may store the ConstantGroup directly resolved so like the class loading in Java, the user should have no way to know if a constant is resolved or not. 
(John, if you wan batch/bulk copy, why not add a method copy() into the List interface (as a default method)) 
I'm also a little worry to introduce that type like this now knowing that get() should return 'any' and not 'Object'. 
3/ I think we can 'retarget' the BootstrapMethods attribute to represent both the values of a ConstantGroup and the values of a ConstantDynamic/InvokeDynamic by saying that the constant values of a ConstantGroup constant in the constant pool is just an index to a BootstrapMethods attribute with a bootstrap_method_ref set to 0. So a ConstantGroup constant is a kind of condy with no bootstrap method. 

R?mi 

[....] 

> 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<T> 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 <T> BootstrapCallInfo<T> 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<Object> asList?()`
> Create a view on this group as a `List` view.
> * `default List<Object> 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<Object> constants, Object
> ifNotPresent, IntFunction<Object> 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/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/BootstrapCallInfo.java#l63
> ]
> [
> http://hg.openjdk.java.net/amber/amber/jdk/file/2744935cd215/src/java.base/share/classes/java/lang/invoke/ConstantGroup.java#l96
> |
> http://hg.openjdk.java.net/amber/amber/jdk/file/2744935cd215/src/java.base/share/classes/java/lang/invoke/ConstantGroup.java#l96
> ]

From karen.kinnear at oracle.com  Wed Sep  6 16:58:14 2017
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 6 Sep 2017 12:58:14 -0400
Subject: Valhalla EG meetings - updated zoom link
Message-ID: <547D835B-F5D7-415A-BBC9-10EE019D84FE@oracle.com>

The meeting time will continue to be Wednesday, e.g. next week September 13th
biweekly at 9am PT/ noon ET / 17 Dublin/ 18 France / 19 St Petersburg

The new zoom link is:

https://oracle.zoom.us/j/5249803466

Audio Information - Join by phone: 

    +1 646 558 8656 or +1 669 900 6833 US Toll
    Meeting ID: 524 980 3466 


thanks,
Karen




From forax at univ-mlv.fr  Thu Sep  7 21:47:32 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 7 Sep 2017 23:47:32 +0200 (CEST)
Subject: vastore and vaload
Message-ID: <378457459.2274061.1504820852513.JavaMail.zimbra@u-pem.fr>

I've just discovered that while the spec specified that vaload and vastore takes a constant class as parameter, the implementation use vaload and vastore with no parameter (like aaload, aastore).

Let see the tradeoffs:
1/ vaload/vastore <empty>  has the same bytecode shape as the other *aload/*astore, need to get the header of the array to find how to shift from one array cell to another,
                           it also mean you call the same vaload/vastore at a bci with array of different value types, which is pure evil from the JIT POV.
                           I believe it's only true if the verifier is deactivated otherwise, you need to have a stackframe when joining two different kinds of array.
                          
2/ vaload/vastore valueref has the same model as the other *aload/*astore bytecode, you can precompute the shift from one array cell to another.

so apart from the size of the opcodes, i think i prefer the solution 2.

Do i miss something ?

regards,
R?mi

From karen.kinnear at oracle.com  Mon Sep 11 16:05:05 2017
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Mon, 11 Sep 2017 12:05:05 -0400
Subject: Valhalla EG minutes Aug 30
Message-ID: <17EE2875-5BBD-4C69-A2E8-975445FB9859@oracle.com>

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 attribute name proposals for Dan Smith
AI: Dan Smith - invoke interface allowing private method invocation - is it ok to allow for older class file versions?
AI: All - for nestmates - send to Dan Smith (and copy us all) implementation paths that would need to check for
nest mate membership - so we can ensure the JVMS reflects potential LinkageErrors etc.
AI: Maurizio - send example to Bjorn of code that works today, but would not work with eager nest top loading
AI: What does reflection get_enclosing_class do if for example the enclosing class has been deleted?
AI: Spec leads: discuss with Groovy & Scala folks any issues with removing ACC_SUPER support. Also whether this change needs to be class file version specific.

Attendees: Remi, Bjorn, Dan Smith, John, Frederic, Lois, Maurizio, Karen

MVT JVMS
1. getfield 
Remi: getfield bytecode for reading of field in Derived Value Class needs similar special handling as vwithfield in allowing the Value Capable Class read access to a private field in the DVC. Dan ok with proposed change

Question: timing of nestmates relative to MVT so we could propose VCC and DVC as nestmates in MVT?
Answer: Expect MVT to be available as early access, so before nestmates
Q: Remi: How do you add to a nest if you can?t add to the nest members attribute?
A: John: You can add dynamic nest members
Editor?s note: I think we need to clarify what reflection shows 

Implementation note: Remi: vwithfield currently has a bug - VCC can not change the field in DVC - throws IAE
====
Condy JVMS:

Remi: Request for a true constant pool constant - today restricted to LDC or indy in BSM
Want to use for constant pool patching like unsafe.defineAnonymousClass
Bjorn: can we dynamically load the BSM name?
John: Larger changes could lead to security issues. We are expecting MethodHandle Combinators.
Want constant pool template abilities, prefer to use MethodHandles as template carrier. Goal is
to quantify over types not over names

Bjorn: BSM args can be condy? 
A: Yes
Discussion of implementation optimizations for condy. Note it uses a BootstrapMethod.

Remi: bootstrap issue - can?t use lambdas - just like today you can?t use BSM until e.g. java.lang.invoke is loaded
John: think about constant lambdas during bootstrap. Longer term AOT and jlink should help with condy

Karen: concern about JVMTI spec and redefineclasses ability to change attributes, so BSM attribute could change.
John: sent an email reply

John:
Condy phasing:
1) basic condy
2) jumbo arty with args for BSM in general
3) BootStrapCallInfo - API point - later
4) Constant_Group - even later - not yet spec?d

Lazy resolution may be delayed, initially all resolution will be eager

Remi: Constant_Group in constant pool or as an attribute?
John: due to size - potentially 1000?s, maybe attribute
Bjorn: what is a ?kiddie pool?? What about constant pool holes?
John: specialization - plugs small number of constant pool holes
[editor?s note: John - what was a kiddie pool referring to?]

Dan Smith: Why 2 arguments? What a Lookup and a separate BSCI?
John: Put Lookup separately - it is uniquely security sensitive
Remi: Lookup isn?t constant
John: can LDC a Lookup

====
Nest mates

Remi: Good with not changing invokespecial
Naming bikeshed: What about changing ?MemberofNest? to ?Nest? - similar to superclass
John: original challenge was the direction - was this the declarer/owner of nest or a member?
See AIs for attribute name proposals.

Q: Are the invoke interface changes classfile version specific?
Note: Can still do invoke special of a local private interface method since it falls under the superclass method invocation
If Invokeinterface throws an exception today for invocation of a private method, is it ok to eliminate this error in future with
existing class file version? 
AI: Dan to investigate
Note: check current TCK tests

John: LONGER TERM: goal to deprecate invoke interface and just have a single virtual invocation with either a MethodReference
or an Interface MethodReference. 
Editor?s note: internally sounds like both IBM and Hotspot would continue to use an internal byte code - at least for now - the
MethodReference and InterfaceMethodReference rules are different, and for hotspot the caching of resolved method is different - for
classes we need a virtual method table index, for interfaces we need an interface method table index relative to the super interface, i.e. two pieces of information

Karen: Future: would like to evolve away from ACC_SUPER allowing invoke special to refer to an indirect super class which requires re-resolution relative to the direct super class.
John: File a specification RFE and get started.
Karen: Need javac to stop using invoke special on java.lang.Object references that have not been overridden at compile time.
John: longer term goal: stricter vm - 
AI: discuss with Groovy & Scala folks any issues with this change. Also whether this change needs to be class file version specific.

Dan: Bigger discussion - can we remove support for older class file versions?
Remi: Sees 1% still running 1.0, 1.1. Tools like ASM can choose not to support
John: defacto policy - continue to run older version


Maurizio:
Need to clarify in specification the timing of checking nest membership. We do not want this in the verifier since it can cause
errors in code that works today.
   If you take an existing example of code in which javac generates a trampoline to access for example an outer class member,
if you then delete the outer class, or if the inner class can not see the outer class due to it being loaded by a different class loader
 - today if you run code that does not use the trampoline it will succeed. 
With nestmates, if the outer class is the nest holder, if you delete that class, then you can not run the inner class since the
verifier will fail trying to check nest membership.

Bjorn: propose load supers and nest top at the same time - issue if a subclass is the nest owner, you can run into circularity issues,
so proposed delay until after loading the class but before verifying the class to avoid circularity.

Maurizio: propose changing the specification to first touch
i.e. first access check of a private member trying to touch a nest mate
Dan: note: if the member is actually private, should not need to perform the nest mate check, so no need to touch the nest
? method handle, access checks which need to know membership would trigger the check and potentially
throw an exception. i.e. any path that would check nest membership.
Bjorn: agreed with proposal

Karen: Dynamically adding a class into a nest should throw an exception for an invalid nest mate.

Remi: A dynamic check would throw a more meaningful error at a time that would be expected - e.g. an IllegalAccessError with
a meaningful message (or cause)

AI: send to Dan Smith - implementation paths that run into checking nest membership

Bjorn: Issues with checking nest membership
- not find a nest top, not claim me in the nest 
[Bjorn - my notes were not clear on what you were asking]
John: For example, an IAE may wrap a LinkageException
Karen: Reflection - what should reflection return when it runs into errors finding nest members
   e.g. if you ask for all
Possible approach? What does get_enclosing_class do today? T
Remi: for dynamic languages - use reflection to check if you can do something so need behavior to be the same as byte code
behavior


From forax at univ-mlv.fr  Wed Sep 13 14:22:47 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 13 Sep 2017 16:22:47 +0200 (CEST)
Subject: Valhalla EG minutes Aug 30
In-Reply-To: <17EE2875-5BBD-4C69-A2E8-975445FB9859@oracle.com>
References: <17EE2875-5BBD-4C69-A2E8-975445FB9859@oracle.com>
Message-ID: <803822355.1776642.1505312567248.JavaMail.zimbra@u-pem.fr>

> AI: What does reflection get_enclosing_class do if for example the enclosing class has been deleted?
NoClassDefFoundError

And if you do the same with an annotation, getAnnotations() skip the annotation.
(Obviously isAnnotationPresent() and getAnnotation() does not work because they takes the class as argument)

R?mi

----- Mail original -----
> De: "Karen Kinnear" <karen.kinnear at oracle.com>
> ?: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoy?: Lundi 11 Septembre 2017 18:05:05
> Objet: 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 attribute name proposals for Dan Smith
> AI: Dan Smith - invoke interface allowing private method invocation - is it ok
> to allow for older class file versions?
> AI: All - for nestmates - send to Dan Smith (and copy us all) implementation
> paths that would need to check for
> nest mate membership - so we can ensure the JVMS reflects potential
> LinkageErrors etc.
> AI: Maurizio - send example to Bjorn of code that works today, but would not
> work with eager nest top loading
> AI: What does reflection get_enclosing_class do if for example the enclosing
> class has been deleted?
> AI: Spec leads: discuss with Groovy & Scala folks any issues with removing
> ACC_SUPER support. Also whether this change needs to be class file version
> specific.
> 
> Attendees: Remi, Bjorn, Dan Smith, John, Frederic, Lois, Maurizio, Karen
> 
> MVT JVMS
> 1. getfield
> Remi: getfield bytecode for reading of field in Derived Value Class needs
> similar special handling as vwithfield in allowing the Value Capable Class read
> access to a private field in the DVC. Dan ok with proposed change
> 
> Question: timing of nestmates relative to MVT so we could propose VCC and DVC as
> nestmates in MVT?
> Answer: Expect MVT to be available as early access, so before nestmates
> Q: Remi: How do you add to a nest if you can?t add to the nest members
> attribute?
> A: John: You can add dynamic nest members
> Editor?s note: I think we need to clarify what reflection shows
> 
> Implementation note: Remi: vwithfield currently has a bug - VCC can not change
> the field in DVC - throws IAE
> ====
> Condy JVMS:
> 
> Remi: Request for a true constant pool constant - today restricted to LDC or
> indy in BSM
> Want to use for constant pool patching like unsafe.defineAnonymousClass
> Bjorn: can we dynamically load the BSM name?
> John: Larger changes could lead to security issues. We are expecting
> MethodHandle Combinators.
> Want constant pool template abilities, prefer to use MethodHandles as template
> carrier. Goal is
> to quantify over types not over names
> 
> Bjorn: BSM args can be condy?
> A: Yes
> Discussion of implementation optimizations for condy. Note it uses a
> BootstrapMethod.
> 
> Remi: bootstrap issue - can?t use lambdas - just like today you can?t use BSM
> until e.g. java.lang.invoke is loaded
> John: think about constant lambdas during bootstrap. Longer term AOT and jlink
> should help with condy
> 
> Karen: concern about JVMTI spec and redefineclasses ability to change
> attributes, so BSM attribute could change.
> John: sent an email reply
> 
> John:
> Condy phasing:
> 1) basic condy
> 2) jumbo arty with args for BSM in general
> 3) BootStrapCallInfo - API point - later
> 4) Constant_Group - even later - not yet spec?d
> 
> Lazy resolution may be delayed, initially all resolution will be eager
> 
> Remi: Constant_Group in constant pool or as an attribute?
> John: due to size - potentially 1000?s, maybe attribute
> Bjorn: what is a ?kiddie pool?? What about constant pool holes?
> John: specialization - plugs small number of constant pool holes
> [editor?s note: John - what was a kiddie pool referring to?]
> 
> Dan Smith: Why 2 arguments? What a Lookup and a separate BSCI?
> John: Put Lookup separately - it is uniquely security sensitive
> Remi: Lookup isn?t constant
> John: can LDC a Lookup
> 
> ====
> Nest mates
> 
> Remi: Good with not changing invokespecial
> Naming bikeshed: What about changing ?MemberofNest? to ?Nest? - similar to
> superclass
> John: original challenge was the direction - was this the declarer/owner of nest
> or a member?
> See AIs for attribute name proposals.
> 
> Q: Are the invoke interface changes classfile version specific?
> Note: Can still do invoke special of a local private interface method since it
> falls under the superclass method invocation
> If Invokeinterface throws an exception today for invocation of a private method,
> is it ok to eliminate this error in future with
> existing class file version?
> AI: Dan to investigate
> Note: check current TCK tests
> 
> John: LONGER TERM: goal to deprecate invoke interface and just have a single
> virtual invocation with either a MethodReference
> or an Interface MethodReference.
> Editor?s note: internally sounds like both IBM and Hotspot would continue to use
> an internal byte code - at least for now - the
> MethodReference and InterfaceMethodReference rules are different, and for
> hotspot the caching of resolved method is different - for
> classes we need a virtual method table index, for interfaces we need an
> interface method table index relative to the super interface, i.e. two pieces
> of information
> 
> Karen: Future: would like to evolve away from ACC_SUPER allowing invoke special
> to refer to an indirect super class which requires re-resolution relative to
> the direct super class.
> John: File a specification RFE and get started.
> Karen: Need javac to stop using invoke special on java.lang.Object references
> that have not been overridden at compile time.
> John: longer term goal: stricter vm -
> AI: discuss with Groovy & Scala folks any issues with this change. Also whether
> this change needs to be class file version specific.
> 
> Dan: Bigger discussion - can we remove support for older class file versions?
> Remi: Sees 1% still running 1.0, 1.1. Tools like ASM can choose not to support
> John: defacto policy - continue to run older version
> 
> 
> Maurizio:
> Need to clarify in specification the timing of checking nest membership. We do
> not want this in the verifier since it can cause
> errors in code that works today.
>   If you take an existing example of code in which javac generates a trampoline to
>   access for example an outer class member,
> if you then delete the outer class, or if the inner class can not see the outer
> class due to it being loaded by a different class loader
> - today if you run code that does not use the trampoline it will succeed.
> With nestmates, if the outer class is the nest holder, if you delete that class,
> then you can not run the inner class since the
> verifier will fail trying to check nest membership.
> 
> Bjorn: propose load supers and nest top at the same time - issue if a subclass
> is the nest owner, you can run into circularity issues,
> so proposed delay until after loading the class but before verifying the class
> to avoid circularity.
> 
> Maurizio: propose changing the specification to first touch
> i.e. first access check of a private member trying to touch a nest mate
> Dan: note: if the member is actually private, should not need to perform the
> nest mate check, so no need to touch the nest
> ? method handle, access checks which need to know membership would trigger the
> check and potentially
> throw an exception. i.e. any path that would check nest membership.
> Bjorn: agreed with proposal
> 
> Karen: Dynamically adding a class into a nest should throw an exception for an
> invalid nest mate.
> 
> Remi: A dynamic check would throw a more meaningful error at a time that would
> be expected - e.g. an IllegalAccessError with
> a meaningful message (or cause)
> 
> AI: send to Dan Smith - implementation paths that run into checking nest
> membership
> 
> Bjorn: Issues with checking nest membership
> - not find a nest top, not claim me in the nest
> [Bjorn - my notes were not clear on what you were asking]
> John: For example, an IAE may wrap a LinkageException
> Karen: Reflection - what should reflection return when it runs into errors
> finding nest members
>   e.g. if you ask for all
> Possible approach? What does get_enclosing_class do today? T
> Remi: for dynamic languages - use reflection to check if you can do something so
> need behavior to be the same as byte code
> behavior

From karen.kinnear at oracle.com  Wed Sep 27 13:50:27 2017
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 27 Sep 2017 09:50:27 -0400
Subject: Valhalla EG meeting Sept 27 - and Sept 13 minutes
Message-ID: <AA8A7EEC-D361-45A8-B297-EA513803ED59@oracle.com>

Reminder - meeting TODAY, Sept 27 9am PT/noon ET/
dial-in:  https://oracle.zoom.us/j/5249803466 <https://oracle.zoom.us/j/5249803466>

AI: Karen send Dan H example in which a BSM can be used for both indy and condy
AI: Dan Smith version of Condy JVMS changes (not an appendix
AI: nestmates JVMS comments: http://cr.openjdk.java.net/~dlsmith/private-access.html
     Remi proposal: rename attribute to ?NestHost"
AI: Karen: write-up preparation relative to selection
AI: Karen - ask Paul progress on VarHandles and atomicity relative to Value Types

Question for EG:

Doug, Charlie - does it work for you if we provide MVT as Early Access Binaries instead of part of 18.3?


Attendees: Remi, Frederic, Brian, Dan H, Karen

1. JDK version numbers relative to class file versions
Would be useful to find a way to document the mapping for users

2. Delivery vehicles
Discussion of making MVT available via an Early Access Binary vs. part of 18.3 experimentally

pros and cons:
1. late in the cycle to be adding to 18.3, specifically relative to JVMS/JCP process
2. with EA binary we can make this available sooner than 18.3, and update it more often in response to requests
and prototype progress
3. EA is less cost to productize and support
4. - the risk of not being in 18.3 is that we will get fewer adopters
   - the hoped for benefit of an EA is that we will get more of the advanced early adopters who can give us valuable
     feedback and use cases
5. No 18.3 features are dependent on MVT (note: pattern matching is not dependent on MVT, and not targeted for 18.3)
    current goal for features: Local Variable Type Inference and Condy (not experimental) in 18.3
    goal: nestmates early in the 18.9 cycle to shake it out (meeting attendees ok with delaying nestmates)
4. As an EA binary, we are ok with having a javac with MVT support behind a flag
5. Benefit of 18.3 experimental: 2nd level customer, i.e. user of Scala or JRuby could enable this with a flag
    - the theory is that those trying the experimental compiler would be able to download an experimental JDK binary to try it on
6. Time to get an experimental feature through JCP process - into experimental appendix with disclaimers
    - Brian working with JCP to reduce lag time, see JSR 383 for 18.3
7. IBM can find a way to do external binaries
    - both IBM and Hotspot are working on internal processes to make this happen
    - we will keep in contact on the target date - not expected to be exactly in sync
    - Hotspot expect ~ 4-6 weeks from Sept 13

3. ConstantDynamic concerns:
   1. BootstrapCallInfo - i.e. lazy resolution - IBM less confident (Hotspot agree)
   Remi wants to continue the discussion
   There are ways to handle > 251 arguments with varargs, rather than requiring BSCI
   channeling John: one of the goals of lazy resolution is to allow only evaluating a subset of constants that may succeed

   2. Question - can a condy and an indy share the same BSM?
       In practice yes - if the BSM specifies a java.lang.Object for the MethodType returned, then it can return a java.lang.Class for the condy
       and a CallSite for the invoke dynamic. The verifier does not check the BSM MethodType, deliberately. The verifier does minimal checking
       for BSMs deliberately, according to Remi - this provides requested flexibility for dynamic languages

    3. Remi - we want condy without java.lang.invoke, and we want it to work during vm bootstrapping.
    

4. Nestmates
  1. Question: how do we handle invokeinterface for methods in java.lang.Object?
AI: Karen to email details of invocation including corner cases - relative to the specification changes

   2. Lazy loading - what should reflection do?
      Request from last meeting to lazily load the nest top so as to not break current nested class examples that work today (e.g. someone deletes the outer class)
      Proposal:
           get list of Nestmates: model on getAnnotations - if you can?t find a nest member, skip it, do not throw an exception
[ed. note: what if you can not find the nest top?]
           check if two types are nestmates: throw LinkageError if nest top can not be found

   3. Attribute renaming: Proposal ?NestHost? from last time -> tell Dan Smith

5. MVT 
    1. Remi: OutOfMemoryError if 15 million element array of ValueTypes
    If fail due to OOME, could consider falling back to allocating in the heap, this would be slower
    Remi: prefer OOME to not performant
    note: choosing to flatten is an implementation detail which could be architecture dependent, depend on atomicity requirements, etc. - no user control

    2. Atomic operations
       Karen: request changing VarHandles to require declaration site atomicity and consistency across byte code and VarHandle access relative to non-tearing
       Remi - less than 64 bits no need to declare
       AI: Karen ask Paul to work with Doug on this
       Remi: please do not reuse volatile, do not use atomic - want e.g. untearable

optional flattening work in progress - should be there in a couple of weeks
       




From forax at univ-mlv.fr  Wed Sep 27 16:14:23 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 27 Sep 2017 18:14:23 +0200 (CEST)
Subject: ConstantDynamic JVMS comments
In-Reply-To: <971262036.2409354.1504305582779.JavaMail.zimbra@u-pem.fr>
References: <5DB8EBD6-BCFE-44A7-869C-ACFB6216767E@oracle.com>
 <604670E8-5DF0-45C1-9F7F-789B69CE0941@oracle.com>
 <971262036.2409354.1504305582779.JavaMail.zimbra@u-pem.fr>
Message-ID: <440362434.3257959.1506528863573.JavaMail.zimbra@u-pem.fr>

ping ! 

R?mi 

> De: "Remi Forax" <forax at univ-mlv.fr>
> ?: "John Rose" <john.r.rose at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoy?: Samedi 2 Septembre 2017 00:39:42
> Objet: Re: ConstantDynamic JVMS comments

> Hi John,

> Thinking a little bit about that,
> 1/ conceptually a BootstrapCallInfo and a ConstantGroup are every similar, it's
> a bunch of constants, the BootstrapCallInfo as just a special meaning for some
> of them.
> 2/ at runtime, it's like an array or a java.util.List (again conceptually) of
> stable values which is lazily populated

> Bold claims:
> 1/ we do not need both BootstrapCallInfo and ConstantGroup, only one is enough,
> yes it means that an indy of a condy BSM will have at least 4 parameters
> (lookup, name, type, constantgroup),
> constantgroup play the role of kind of array (a new kind of Array 2.0 ?)
> 2/ ConstantGroup should only have two methods, size() and get(index) (and
> perhaps asList() for interropt), the fact that asking for a value will trigger
> an initialization or not should not be part of the spec.
> There is a good reason for that, an image format like CDS may store the
> ConstantGroup directly resolved so like the class loading in Java, the user
> should have no way to know if a constant is resolved or not.
> (John, if you wan batch/bulk copy, why not add a method copy() into the List
> interface (as a default method))
> I'm also a little worry to introduce that type like this now knowing that get()
> should return 'any' and not 'Object'.
> 3/ I think we can 'retarget' the BootstrapMethods attribute to represent both
> the values of a ConstantGroup and the values of a ConstantDynamic/InvokeDynamic
> by saying that the constant values of a ConstantGroup constant in the constant
> pool is just an index to a BootstrapMethods attribute with a
> bootstrap_method_ref set to 0. So a ConstantGroup constant is a kind of condy
> with no bootstrap method.

> R?mi

> [....]

>> 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<T> 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 <T> BootstrapCallInfo<T> 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<Object> asList?()`
>> Create a view on this group as a `List` view.
>> * `default List<Object> 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<Object> constants, Object
>> ifNotPresent, IntFunction<Object> 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/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/BootstrapCallInfo.java#l63
>> ]
>> [
>> http://hg.openjdk.java.net/amber/amber/jdk/file/2744935cd215/src/java.base/share/classes/java/lang/invoke/ConstantGroup.java#l96
>> |
>> http://hg.openjdk.java.net/amber/amber/jdk/file/2744935cd215/src/java.base/share/classes/java/lang/invoke/ConstantGroup.java#l96
>> ]

From paul.sandoz at oracle.com  Wed Sep 27 16:38:55 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 27 Sep 2017 09:38:55 -0700
Subject: Valhalla EG meeting Sept 27 - and Sept 13 minutes
In-Reply-To: <AA8A7EEC-D361-45A8-B297-EA513803ED59@oracle.com>
References: <AA8A7EEC-D361-45A8-B297-EA513803ED59@oracle.com>
Message-ID: <6457F745-0CB9-46E5-898D-3F5D49DDA3F6@oracle.com>


> On 27 Sep 2017, at 06:50, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> Reminder - meeting TODAY, Sept 27 9am PT/noon ET/
> dial-in:  https://oracle.zoom.us/j/5249803466 <https://oracle.zoom.us/j/5249803466>
> 
> AI: Karen send Dan H example in which a BSM can be used for both indy and condy
> AI: Dan Smith version of Condy JVMS changes (not an appendix
> AI: nestmates JVMS comments: http://cr.openjdk.java.net/~dlsmith/private-access.html <http://cr.openjdk.java.net/~dlsmith/private-access.html>
>      Remi proposal: rename attribute to ?NestHost"
> AI: Karen: write-up preparation relative to selection
> AI: Karen - ask Paul progress on VarHandles and atomicity relative to Value Types
> 

Alas very little :-( Most effort has been focused on bashing condy (minus BSCI) into shape for integration.

Paul.

From karen.kinnear at oracle.com  Wed Sep 27 13:58:38 2017
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Wed, 27 Sep 2017 13:58:38 -0000
Subject: Valhalla EG meeting Sept 27 - and Sept 13 minutes
In-Reply-To: <AA8A7EEC-D361-45A8-B297-EA513803ED59@oracle.com>
References: <AA8A7EEC-D361-45A8-B297-EA513803ED59@oracle.com>
Message-ID: <A64C90E3-60CD-4693-BEC9-B3F9F6154CCC@oracle.com>

Write-up on preparation relative to selection and nest mate JVMS changes. Feedback welcome.


> On Sep 27, 2017, at 9:50 AM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> Reminder - meeting TODAY, Sept 27 9am PT/noon ET/
> dial-in:  https://oracle.zoom.us/j/5249803466 <https://oracle.zoom.us/j/5249803466>
> 
> AI: Karen send Dan H example in which a BSM can be used for both indy and condy
> AI: Dan Smith version of Condy JVMS changes (not an appendix
> AI: nestmates JVMS comments: http://cr.openjdk.java.net/~dlsmith/private-access.html <http://cr.openjdk.java.net/~dlsmith/private-access.html>
>      Remi proposal: rename attribute to ?NestHost"
> AI: Karen: write-up preparation relative to selection
> AI: Karen - ask Paul progress on VarHandles and atomicity relative to Value Types
> 
> Question for EG:
> 
> Doug, Charlie - does it work for you if we provide MVT as Early Access Binaries instead of part of 18.3?
> 
> 
> Attendees: Remi, Frederic, Brian, Dan H, Karen
> 
> 1. JDK version numbers relative to class file versions
> Would be useful to find a way to document the mapping for users
> 
> 2. Delivery vehicles
> Discussion of making MVT available via an Early Access Binary vs. part of 18.3 experimentally
> 
> pros and cons:
> 1. late in the cycle to be adding to 18.3, specifically relative to JVMS/JCP process
> 2. with EA binary we can make this available sooner than 18.3, and update it more often in response to requests
> and prototype progress
> 3. EA is less cost to productize and support
> 4. - the risk of not being in 18.3 is that we will get fewer adopters
>    - the hoped for benefit of an EA is that we will get more of the advanced early adopters who can give us valuable
>      feedback and use cases
> 5. No 18.3 features are dependent on MVT (note: pattern matching is not dependent on MVT, and not targeted for 18.3)
>     current goal for features: Local Variable Type Inference and Condy (not experimental) in 18.3
>     goal: nestmates early in the 18.9 cycle to shake it out (meeting attendees ok with delaying nestmates)
> 4. As an EA binary, we are ok with having a javac with MVT support behind a flag
> 5. Benefit of 18.3 experimental: 2nd level customer, i.e. user of Scala or JRuby could enable this with a flag
>     - the theory is that those trying the experimental compiler would be able to download an experimental JDK binary to try it on
> 6. Time to get an experimental feature through JCP process - into experimental appendix with disclaimers
>     - Brian working with JCP to reduce lag time, see JSR 383 for 18.3
> 7. IBM can find a way to do external binaries
>     - both IBM and Hotspot are working on internal processes to make this happen
>     - we will keep in contact on the target date - not expected to be exactly in sync
>     - Hotspot expect ~ 4-6 weeks from Sept 13
> 
> 3. ConstantDynamic concerns:
>    1. BootstrapCallInfo - i.e. lazy resolution - IBM less confident (Hotspot agree)
>    Remi wants to continue the discussion
>    There are ways to handle > 251 arguments with varargs, rather than requiring BSCI
>    channeling John: one of the goals of lazy resolution is to allow only evaluating a subset of constants that may succeed
> 
>    2. Question - can a condy and an indy share the same BSM?
>        In practice yes - if the BSM specifies a java.lang.Object for the MethodType returned, then it can return a java.lang.Class for the condy
>        and a CallSite for the invoke dynamic. The verifier does not check the BSM MethodType, deliberately. The verifier does minimal checking
>        for BSMs deliberately, according to Remi - this provides requested flexibility for dynamic languages
> 
>     3. Remi - we want condy without java.lang.invoke, and we want it to work during vm bootstrapping.
>     
> 
> 4. Nestmates
>   1. Question: how do we handle invokeinterface for methods in java.lang.Object?
> AI: Karen to email details of invocation including corner cases - relative to the specification changes
> 
>    2. Lazy loading - what should reflection do?
>       Request from last meeting to lazily load the nest top so as to not break current nested class examples that work today (e.g. someone deletes the outer class)
>       Proposal:
>            get list of Nestmates: model on getAnnotations - if you can?t find a nest member, skip it, do not throw an exception
> [ed. note: what if you can not find the nest top?]
>            check if two types are nestmates: throw LinkageError if nest top can not be found
> 
>    3. Attribute renaming: Proposal ?NestHost? from last time -> tell Dan Smith
> 
> 5. MVT 
>     1. Remi: OutOfMemoryError if 15 million element array of ValueTypes
>     If fail due to OOME, could consider falling back to allocating in the heap, this would be slower
>     Remi: prefer OOME to not performant
>     note: choosing to flatten is an implementation detail which could be architecture dependent, depend on atomicity requirements, etc. - no user control
> 
>     2. Atomic operations
>        Karen: request changing VarHandles to require declaration site atomicity and consistency across byte code and VarHandle access relative to non-tearing
>        Remi - less than 64 bits no need to declare
>        AI: Karen ask Paul to work with Doug on this
>        Remi: please do not reuse volatile, do not use atomic - want e.g. untearable
> 
> optional flattening work in progress - should be there in a couple of weeks
>        
> 
> 
>