Computed Constants API question

[Per-Ake Minborg]

Hi Chen,

Thanks for trying ComputedConstants!

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.

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.
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
________________________________
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<mailto: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/20230828/0000efb8/attachment.htm>