Computed Constants API question

[David Alayachew]

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/8cc3b69d/attachment.htm>