Computed Constants API question

[David Alayachew]

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/719d62d5/attachment.htm>