Computed Constants API question

Fri Sep 1 09:28:48 UTC 2023

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