RFR: JDK-8282798 java.lang.runtime.Carrier

[Brian Goetz]

It is a base assumption that the specific representation — bits in an int[], a class per shape, a cache of common shapes, etc — is a pure implementation detail that can be changed at will, based on various tradeoffs like footprint-vs-startup that can be made at any time.  The only assumption is that when you pass a shape to the constructor() method, the same (hidden) representation will be used when you pass the same shape in the same JVM invocation to the component() methods.  

Having a List<MH> view fo the components may help because of the internal @Stable annotation.  

For pattern matching, we envision storing the accessor MHs in condy at the use site.  String templates probably has a different expected user model.  

> On Mar 8, 2022, at 11:04 AM, Maurizio Cimadamore <mcimadamore at openjdk.java.net> wrote:
> 
> On Tue, 8 Mar 2022 14:02:39 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:
> 
>> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. 
>> 
>> See JBS for details.
> 
> Looks good.
> I've left some minor doc-related comments.
> When reading (as discussed online) I wondered if using Unsafe to access values inside a byte[] or Object[] would simplify the carrier implementation somehow.
> 
> src/java.base/share/classes/java/lang/runtime/Carrier.java line 48:
> 
>> 46: 
>> 47: /**
>> 48:  * This  class is used to create objects that have number and types of
> 
> The class javadoc seems a bit on the thin side. I would say something on the fact that the shape of the carrier is determined by a MethodType, etc, and add an example to illustrate basic usage.
> 
> src/java.base/share/classes/java/lang/runtime/Carrier.java line 129:
> 
>> 127: 
>> 128:     /**
>> 129:      * Factory for array based carrier. Array wrapped in object to provide
> 
> I found this comment hard to parse - or unhelpful to understand how the factory really worked. IIUC, this factory captures all parameters into an Object[] (using a collector MH) and returns that Object[] (which acts as the carrier object). I'm not sure I see anything here that would prevent the user from building a carrier and casting to Object[] ?
> 
> src/java.base/share/classes/java/lang/runtime/Carrier.java line 432:
> 
>> 430:          * Construct a new object carrier class based on shape.
>> 431:          *
>> 432:          * @param carrierShape  shape of carrier
> 
> Suggestion:
> 
>         * @param carrierShape shape of carrier
> 
> src/java.base/share/classes/java/lang/runtime/Carrier.java line 633:
> 
>> 631:          * getter.
>> 632:          *
>> 633:          * @param i  index of component to get
> 
> Suggestion:
> 
>         * @param i index of component to get
> 
> src/java.base/share/classes/java/lang/runtime/Carrier.java line 656:
> 
>> 654: 
>> 655:     /**
>> 656:      * Find or create carrier class for a carrioer shape.
> 
> Suggestion:
> 
>     * Find or create carrier class for a carrier shape.
> 
> src/java.base/share/classes/java/lang/runtime/Carrier.java line 852:
> 
>> 850:      * @throws IllegalArgumentException if number of component slots exceeds maximum
>> 851:      */
>> 852:     public static MethodHandle constructor(MethodType methodType) {
> 
> What happens to the methodType return type? (both here and in the components method). Should javadoc say anything?
> 
> -------------
> 
> Marked as reviewed by mcimadamore (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/7744