Computed Constants API question

[-]

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/4227fbca/attachment.htm>