Computed Constants API question

[David Alayachew]

Makes sense, ty for the clarification.

On Fri, Sep 1, 2023 at 10:49 AM - <liangchenblue at gmail.com> wrote:

> Hi David,
>
> I was talking about how an Object can have multiple representations (say
> one in byte-stream format and another in JSON), we can construct the object
> from either format; and we might convert it back. In the case where we
> construct from either format, we can cache the value in that format at
> construction rather than using a CC to cache it later.
>
> Per has offered a nice solution, that I can declare the field type as
> Supplier<T>, and immediately-available values can be a plain supplier like
> `() -> byteStream`. And this seems good, given lambdas are hidden classes
> with trusted final fields, so this should still be constant-foldable.
>
> Chen Liang
>
> On Fri, Sep 1, 2023 at 9:20 PM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Hello Chen Liang,
>>
>> One other point I wanted to add.
>>
>> If we do go down the route of doing an immediate() method, it might sound
>> stupid, but I actually think it should still be given a Supplier vs the
>> value itself. Immediate seems intuitive at first glance, but we are talking
>> about a new world where our program can do work PRE-EXECUTION. The
>> metaphorical ground is shifting underneath our feet. I would think that
>> forcing the developer to type 6 extra characters [() -> ] would clue them
>> in to the type of capabilities they are enabling. Perhaps I am wildly off
>> the mark.
>>
>> Thank you for your time!
>> David Alayachew
>>
>> On Fri, Sep 1, 2023 at 9:18 AM David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>>> Hello Chen Liang,
>>>
>>> I had trouble understanding your first paragraph, but it sounds like you
>>> wanted something similar to CompletableFuture.completedFuture(), but for
>>> CC, right? If so, then while I would normally agree, I'm actually not sure
>>> whether that's wise to do RIGHT NOW or not.
>>>
>>> The entire point behind CC was to facilitate Leyden's goals of
>>> shifting/condensing work. In this case, that means that we get more
>>> flexibility and control for when we initialize our constants. But at the
>>> moment, we don't know what that flexibility and control looks like.
>>> Obviously, CC gets initialized when you call CC.get(), but that is not its
>>> only purpose. It could also become a "blessed-class" (as someone else put
>>> it, I forget who) that we could add some extra controls to, either
>>> internally, externally, or elsewhere. Meaning, we could have a
>>> Leyden-specific feature that gives us the ability to load the data at a
>>> very different time than the CC library currently permits.
>>>
>>> Knowing that, I feel like it would make more sense to get a better idea
>>> of what it looks like to shift computation forwards or backwards before we
>>> give developers the ability to limit that anyways. Otherwise, I foresee
>>> developers choosing the option that is more easily comprehensible, and
>>> limiting (if not forgoing) the bigger benefits that Leyden might offer us.
>>> More specifically, I think it might be better for developers to get a
>>> handle on how the basics of CC work before we start introducing shortcut
>>> methods that could double as effectiveness-killers when they use them the
>>> wrong way. Once developers have a grasp on CC, and it's shown that its use
>>> is well understood by the community, then adding methods like immediate()
>>> makes sense.
>>>
>>> On the other hand, maybe that's for the better - Leyden is going to
>>> require a higher skill level from its end users (developers) than some of
>>> the other projects (Amber) because it focuses on solving a sticky problem
>>> that can easily be overlooked (how to control/minimize your
>>> startup/footprint/memory-use/etc).
>>>
>>> But I wanted to bring up this point so that we keep in mind what
>>> behaviours we encourage by having certain methods available to developers.
>>>
>>> Thank you for your time!
>>> David Alayachew
>>>
>>> On Fri, Sep 1, 2023 at 7:24 AM - <liangchenblue at gmail.com> wrote:
>>>
>>>> Hi Per,
>>>> For the record constructor, I understand that a record can use a CC
>>>> field that carries independent data; what I meant was another scenario,
>>>> where some information derived from record data (thus dependent on other
>>>> record fields and shouldn't be set via a constructor, not tearable, like
>>>> the "atomic" concept in Valhalla's non-atomic debate) is computed once,
>>>> stored in CC, and shared down the line, such as an expensive toString
>>>> result. Such scenarios force us to abandon records unfortunately.
>>>>
>>>> That said, is there a point to introduce an immediately-available CC
>>>> where the value is already provided? For example, if the descriptor string
>>>> is provided instead of a return type and a list of parameter types to
>>>> construct a Method Type Descriptor, the CC<String> descriptorString can be
>>>> an immediate object [1], instead of a supplier that builds a string from
>>>> the types. Something like:
>>>>
>>>> public static <V> ComputedConstant<V> immediate(V value)
>>>>
>>>> Chen Liang
>>>>
>>>> [1]:
>>>> https://github.com/openjdk/jdk/blob/033f311abccc45567230c69c6e0f6d1746f3c7e4/src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java#L102
>>>>
>>>> On Fri, Sep 1, 2023 at 5:03 PM Per-Ake Minborg <
>>>> per-ake.minborg at oracle.com> wrote:
>>>>
>>>>> Hi Chen and Mateusz,
>>>>>
>>>>> As Chen mentioned, we anticipate CCs can be used in many cases. I am
>>>>> not sure what would be the difference between a record constructor and a
>>>>> normal-class constructor though when it comes to passing a CC?
>>>>>
>>>>> We have experimented with a large number of constructs around CCs, for
>>>>> example using Enums as keys and having a general mapping from an integer
>>>>> value to a slot in a List/Array. Of all those, I think it is most likely
>>>>> that we will see point (2), that Chen mentioned, appearing in the API
>>>>> in the future. But, as always, we make no promises.
>>>>>
>>>>> Thanks for the feedback.
>>>>>
>>>>> Best, Per
>>>>> ------------------------------
>>>>> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
>>>>> *Sent:* Wednesday, August 30, 2023 5:19 PM
>>>>> *To:* Per-Ake Minborg <per-ake.minborg at oracle.com>
>>>>> *Cc:* Maurizio Cimadamore <maurizio.cimadamore at oracle.com>; Per
>>>>> Minborg <pminborg at openjdk.org>; leyden-dev at openjdk.org <
>>>>> leyden-dev at openjdk.org>
>>>>> *Subject:* Re: Computed Constants API question
>>>>>
>>>>> I agree this is cleaner and more thread safe; the state field is now
>>>>> also a candidate for @Stable laziness, and we will go through fast paths in
>>>>> case of a failed evaluation.
>>>>>
>>>>> Now it appears to me that everywhere in the user code where a @Stable
>>>>> field would help, it can be replaced by a final ComputedConstant, which is
>>>>> satisfactory. They aren't that nice with records, for passing a CC into a
>>>>> record constructor cannot ensure the computation is correct, but otherwise,
>>>>> they can be passed around in private constructors to share caching when
>>>>> available. Is my understanding correct?
>>>>>
>>>>> Returning to the original request, now I request 2 Map-returning APIs
>>>>> that work like our List<ComputedConstant<V>> for ease of use:
>>>>> 1. public static <K, V> Map<K, ComputedConstant<V>> of(int size,
>>>>> ToIntFunction<K> keyMapper, Function<K, V> generator)
>>>>> 2. public static <K, V> Map<K, ComputedConstant<V>> of(Collection<K>
>>>>> allKeys, Function<K, V> generator)
>>>>> (Note: the function's SAM might carry other throwable in its method
>>>>> signature, up to debate; same debate for the regular factory, maybe we can
>>>>> accept Callables too)
>>>>>
>>>>> 1. This is similar to enum-based array cache common in JDK codebase,
>>>>> especially j.l.invoke; it's backed by an array, much like the
>>>>> list-returning version, but it's presented as a Map. The map will not find
>>>>> a mapping if keyMapper returns an out-of-bounds value; this will be
>>>>> constant-foldable if keyMapper is, which we should document.
>>>>> 2. This is similar to your API proposal in the thread replying
>>>>> Alyachev; Its implementation will be much like the
>>>>> ImmutableCollection.MapN, but its values in the array will only be filled
>>>>> on-demand. This map can be constant-foldable if the key's hashCode is,
>>>>> which we should document.
>>>>>
>>>>> How does this new proposal appear to you, Per?
>>>>>
>>>>> Chen Liang
>>>>>
>>>>> On Wed, Aug 30, 2023 at 9:22 PM Per-Ake Minborg <
>>>>> per-ake.minborg at oracle.com> wrote:
>>>>>
>>>>> Hi Chen,
>>>>>
>>>>> We are looking into splitting up the auxiliary field into two separate
>>>>> fields. One final field for the supplier and another field for the holding
>>>>> of CC's state (e.g. if it was evaluated to null, a non-null value etc.).
>>>>>
>>>>> This will make the CC objects a bit larger but will provide several
>>>>> other benefits including simplifying the code and improving performance.
>>>>>
>>>>> Best, Per
>>>>> ------------------------------
>>>>> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
>>>>> *Sent:* Monday, August 28, 2023 3:37 PM
>>>>> *To:* Per-Ake Minborg <per-ake.minborg at oracle.com>
>>>>> *Cc:* Maurizio Cimadamore <maurizio.cimadamore at oracle.com>; Per
>>>>> Minborg <pminborg at openjdk.org>; leyden-dev at openjdk.org <
>>>>> leyden-dev at openjdk.org>
>>>>> *Subject:* Re: Computed Constants API question
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Aug 28, 2023 at 6:30 PM Per-Ake Minborg <
>>>>> per-ake.minborg at oracle.com> wrote:
>>>>>
>>>>> Hi Chen,
>>>>>
>>>>> Thanks for trying ComputedConstants!
>>>>>
>>>>> I'm more than glad to. We finally are able to enjoy constant-folding
>>>>> for array-like structures before frozen arrays arrive :)
>>>>>
>>>>>
>>>>> On top of Maurizio's answers, it should be noted that we have
>>>>> experimented with an array similar to your suggestion early in the
>>>>> prototype phase
>>>>> and, unfortunately, the solution became slow and had a larger
>>>>> footprint. Such solutions must create and hold an individual lambda
>>>>> for each element and both the elements and the lambdas must be
>>>>> calculated eagerly.
>>>>>
>>>>> What if "of(() -> provider.apply(t))" was changed to
>>>>> "ListElementComputedConstant.create(i, provider)"? Does creating the CC
>>>>> without creating a lambda instance incur a huge performance overhead as
>>>>> well? Guess I will take time and try locally with the existing benchmarks.
>>>>>
>>>>>
>>>>> With the on-demand approach, startup times and footprint requirements
>>>>> were significantly better.
>>>>>
>>>>> We also have a similar approach for maps that we are experimenting
>>>>> with. This would provide an on-demand map that is eligible for constant
>>>>> folding optimizations.
>>>>>
>>>>> The on-demand map is definitely better than a non-on-demand one; it
>>>>> has 2 major advantages that merit its inclusion in the API now:
>>>>> 1. The implementation is less likely to be accidentally
>>>>> non-constant-foldable;
>>>>> 2. It will be otherwise difficult for users to implement a on-demand
>>>>> CC map (where each CC is on-demand)
>>>>>
>>>>> The implementation itself won't be hard; we can create another
>>>>> subclass that uses a Function as a provider.
>>>>>
>>>>> In addition, I doubt the volatile write to the provider (auxiliary)
>>>>> [1] suffices: according to Aleksey Shipilyov [2], since
>>>>> AbstractComputedConstant has no final fields, the auxiliary field might be
>>>>> null in a volatile read even if the constructor has returned. Can you
>>>>> explain how this is safe, and if read/write volatile in VarHandle differs
>>>>> from that in regular volatile fields?
>>>>>
>>>>> I think this concept would be great for general lazy calculation but
>>>>> when and if it can make its way into the JEP is unsure.
>>>>>
>>>>> Best, Per
>>>>>
>>>>> No worries. We can always try out, and preview allows us sufficient
>>>>> usage to test out our new APIs.
>>>>>
>>>>> Cheers,
>>>>> Chen
>>>>>
>>>>> [1]
>>>>> https://github.com/openjdk/leyden/blob/591689ed312977bbd6f99484d3c92e6a12aed9b3/src/java.base/share/classes/jdk/internal/constant/AbstractComputedConstant.java#L74
>>>>> [2]
>>>>> https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-volatiles-are-finals
>>>>>
>>>>> ------------------------------
>>>>> *From:* liangchenblue at gmail.com <liangchenblue at gmail.com>
>>>>> *Sent:* Monday, August 28, 2023 12:08 PM
>>>>> *To:* Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>>>>> *Cc:* Per Minborg <pminborg at openjdk.org>; leyden-dev at openjdk.org <
>>>>> leyden-dev at openjdk.org>
>>>>> *Subject:* Re: Computed Constants API question
>>>>>
>>>>> Thanks Maurizio,
>>>>> This late condensation does explain the peculiarities in the
>>>>> OnDemandComputedConstantList. And I think not providing a List<V> factory
>>>>> is fine, despite the usage complexities: we still need to track the
>>>>> computation state for each element, so having a CC wrapper over each
>>>>> element isn't too bad.
>>>>>
>>>>> I think the OnDemandComputedConstantList implementation is
>>>>> unnecessary; we can just create an array of non-null ComputedConstant
>>>>> elements like:
>>>>>
>>>>> ComputedConstant<T>[] array = new ComputedConstant<?>[size]; //
>>>>> unchecked
>>>>> for (int i = 0; i < size; i++) {
>>>>>     final int t = i;
>>>>>     array[i] = of(() -> provider.apply(t));
>>>>> }
>>>>> return JUCA.listFromTrustedArray(array);
>>>>>
>>>>> Users can use Map.ofEntries to create a Map<K, CC<V>>, but since
>>>>> people might use other types of maps that aren't eligible for
>>>>> Constant-folding, I would recommend providing an official API as well to
>>>>> avoid user errors.
>>>>>
>>>>> The interloping from List<CC<V>> to List<V> (and also that for Maps) can be implemented by users if needed. It shouldn't be too much of a problem, I would assume.
>>>>>
>>>>> Chen Liang
>>>>>
>>>>> On Mon, Aug 28, 2023 at 5:29 PM Maurizio Cimadamore <
>>>>> maurizio.cimadamore at oracle.com> wrote:
>>>>>
>>>>> Hi,
>>>>> I believe the issues you see in the JEP reflect the fact that the API
>>>>> went through a stage of "late condensation" - we used to
>>>>> ComputedConstant and ComputedList, but the latter has now turned into
>>>>> just a factory on the former. I think the factory provided is the more
>>>>> general (as it allows for different resolution policies).
>>>>>
>>>>> If I recall correctly, the decision _not_ to provide a List<V> factory
>>>>> is motivated by the fact that we would have to respecify that
>>>>> List::get
>>>>> is associated with the same behavior as ComputedConstant::get. That
>>>>> is,
>>>>> that list can act in very weird ways, throw novel exceptions, etc. For
>>>>> these reasons we preferred to make the CC-nature of the list apparent
>>>>> in
>>>>> its generic type, rather than introducing some magic list wrapper
>>>>> which
>>>>> adds its own special behavior (see Collections::unmodifiableList).
>>>>>
>>>>> Now, with that said, I can see this going both ways - while List<CC>
>>>>> is
>>>>> a more explicit and "honest" representation - what you say re. interop
>>>>> with clients accepting just a List<V> is also a valid point (and you
>>>>> can't fully get to a List<V> just by using a Steam mapper, as the
>>>>> terminal operation `asList` would force eager computation of all the
>>>>> constants).
>>>>>
>>>>> Maurizio
>>>>>
>>>>> On 28/08/2023 09:31, - wrote:
>>>>> > Hello Per and Leyden subscribers,
>>>>> > First, I am glad that we are finally adding an API that exposes one
>>>>> of
>>>>> > core libraries' favorite feature, `@Stable`, to common users!
>>>>> >
>>>>> > For the API design, however, I have a request: Can we have a
>>>>> > ComputedConstant factory that creates a List<V> in addition to one
>>>>> > that creates a List<ComputedConstant<V>>?
>>>>> >
>>>>> > I think using the List<ComputedConstant<V>> is confusing. The
>>>>> example
>>>>> > usages in the JEP [1] and in the API specification [2] are already
>>>>> > wrong: we need an extra ConputedConstant.get() call to unwrap the
>>>>> > ComputedConstant after List.get(index) call, which currently returns
>>>>> a
>>>>> > computed constant than the actual value.
>>>>> >
>>>>> > The current List<ComputedConstant<V>> is to be kept in case users
>>>>> want
>>>>> > fine-grained control over each constant's resolution failure, etc.
>>>>> and
>>>>> > covers the new factory's functionality. But I believe the new
>>>>> factory
>>>>> > will see wider usage:
>>>>> >
>>>>> > 1. None of the 2 old patterns in the "Motivation" section uses any
>>>>> of
>>>>> > these exception handling or initialization state detection.
>>>>> > 2. Returning a List<V> allows users to conveniently pass the list in
>>>>> > usages instead of using streams or writing custom wrappers.
>>>>> >
>>>>> > A follow up to a previous request [3], I believe having a map (of
>>>>> type
>>>>> > Map<K, V> instead of Map<K, ComputedConstant<V>>) would be feasible
>>>>> too.
>>>>> >
>>>>> > Finally, a side comment about the current
>>>>> > OnDemandComputedConstantList: it computes ComputedConstant wrappers
>>>>> in
>>>>> > addition to the actual constants on demand, which... seems a bit
>>>>> > overkill, when ComputedConstant itself is already a lightweight
>>>>> > wrapper of a heavy computation?
>>>>> >
>>>>> > Best,
>>>>> > Chen Liang
>>>>> >
>>>>> > [1]: https://openjdk.org/jeps/8312611  "var kbd =
>>>>> lbl.labels.get(3);"
>>>>> > [2]:
>>>>> >
>>>>> https://cr.openjdk.org/~pminborg/computed-constant/api/java.base/java/lang/ComputedConstant.html#of(int,java.util.function.IntFunction)
>>>>> >  "return PO2_CACHE.get(n);"
>>>>> > [3]:
>>>>> https://mail.openjdk.org/pipermail/leyden-dev/2023-August/000277.html
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230901/9315fdcf/attachment.htm>