<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 28, 2023 at 6:30 PM Per-Ake Minborg <<a href="mailto:per-ake.minborg@oracle.com">per-ake.minborg@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg2272718210378170326">




<div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Hi Chen,</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Thanks for trying ComputedConstants!</div></div></div></blockquote><div>I'm more than glad to. We finally are able to enjoy constant-folding for array-like structures before frozen arrays arrive :) </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg2272718210378170326"><div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
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 </div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
and, unfortunately, the solution became slow and had a larger footprint. Such solutions must create and hold an individual lambda</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
for each element and both the elements and the lambdas must be calculated eagerly. <br></div></div></div></blockquote><div>What if "<span style="font-family:arial,sans-serif">of(() -> provider.apply(t))</span>" 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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg2272718210378170326"><div dir="ltr"><div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
With the on-demand approach, startup times and footprint requirements were significantly better.<br>
<br>
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. </div></div></div></blockquote><div>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:</div><div>1. The implementation is less likely to be accidentally non-constant-foldable;</div><div>2. It will be otherwise difficult for users to implement a on-demand CC map (where each CC is on-demand) </div><div><br></div><div>The implementation itself won't be hard; we can create another subclass that uses a Function as a provider.</div><div><br></div><div>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?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg2272718210378170326"><div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
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.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Best, Per</div></div></div></blockquote><div>No worries. We can always try out, and preview allows us sufficient usage to test out our new APIs.</div><div> </div><div>Cheers,</div><div>Chen</div><div><br></div><div>[1] <a href="https://github.com/openjdk/leyden/blob/591689ed312977bbd6f99484d3c92e6a12aed9b3/src/java.base/share/classes/jdk/internal/constant/AbstractComputedConstant.java#L74">https://github.com/openjdk/leyden/blob/591689ed312977bbd6f99484d3c92e6a12aed9b3/src/java.base/share/classes/jdk/internal/constant/AbstractComputedConstant.java#L74</a></div><div>[2] <a href="https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-volatiles-are-finals">https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-volatiles-are-finals</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg2272718210378170326"><div dir="ltr">
<div id="m_2272718210378170326appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="m_2272718210378170326divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> <a href="mailto:liangchenblue@gmail.com" target="_blank">liangchenblue@gmail.com</a> <<a href="mailto:liangchenblue@gmail.com" target="_blank">liangchenblue@gmail.com</a>><br>
<b>Sent:</b> Monday, August 28, 2023 12:08 PM<br>
<b>To:</b> Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.com</a>><br>
<b>Cc:</b> Per Minborg <<a href="mailto:pminborg@openjdk.org" target="_blank">pminborg@openjdk.org</a>>; <a href="mailto:leyden-dev@openjdk.org" target="_blank">leyden-dev@openjdk.org</a> <<a href="mailto:leyden-dev@openjdk.org" target="_blank">leyden-dev@openjdk.org</a>><br>
<b>Subject:</b> Re: Computed Constants API question</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr"><font face="arial, sans-serif">Thanks Maurizio,</font>
<div><font face="arial, sans-serif">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.</font></div>
<div><font face="arial, sans-serif"><br>
</font></div>
<div><font face="arial, sans-serif">I think the OnDemandComputedConstantList implementation is unnecessary; we can just create an array of non-null ComputedConstant elements like:</font></div>
<div><font face="arial, sans-serif"><br>
</font></div>
<div><font face="arial, sans-serif">ComputedConstant<T>[] array = new ComputedConstant<?>[size]; // unchecked</font></div>
<div><font face="arial, sans-serif">for (int i = 0; i < size; i++) {</font></div>
<div><font face="arial, sans-serif">    final int t = i;</font></div>
<div><font face="arial, sans-serif">    array[i] = of(() -> provider.apply(t));</font></div>
<div><font face="arial, sans-serif">}</font></div>
<div><font face="arial, sans-serif">return JUCA.listFromTrustedArray(array);</font></div>
<div><font face="arial, sans-serif"><br>
</font></div>
<div><font face="arial, sans-serif">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.</font></div>
<div>
<pre style="color:rgb(0,0,0)"><font face="arial, sans-serif">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.</font></pre>
</div>
<div><font face="arial, sans-serif">Chen Liang</font></div>
</div>
<font face="arial, sans-serif"><br>
</font>
<div>
<div dir="ltr"><font face="arial, sans-serif">On Mon, Aug 28, 2023 at 5:29 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank">maurizio.cimadamore@oracle.com</a>> wrote:<br>
</font></div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<font face="arial, sans-serif">Hi,<br>
I believe the issues you see in the JEP reflect the fact that the API <br>
went through a stage of "late condensation" - we used to <br>
ComputedConstant and ComputedList, but the latter has now turned into <br>
just a factory on the former. I think the factory provided is the more <br>
general (as it allows for different resolution policies).<br>
<br>
If I recall correctly, the decision _not_ to provide a List<V> factory <br>
is motivated by the fact that we would have to respecify that List::get <br>
is associated with the same behavior as ComputedConstant::get. That is, <br>
that list can act in very weird ways, throw novel exceptions, etc. For <br>
these reasons we preferred to make the CC-nature of the list apparent in <br>
its generic type, rather than introducing some magic list wrapper which <br>
adds its own special behavior (see Collections::unmodifiableList).<br>
<br>
Now, with that said, I can see this going both ways - while List<CC> is <br>
a more explicit and "honest" representation - what you say re. interop <br>
with clients accepting just a List<V> is also a valid point (and you <br>
can't fully get to a List<V> just by using a Steam mapper, as the <br>
terminal operation `asList` would force eager computation of all the <br>
constants).<br>
<br>
Maurizio<br>
<br>
On 28/08/2023 09:31, - wrote:<br>
> Hello Per and Leyden subscribers,<br>
> First, I am glad that we are finally adding an API that exposes one of <br>
> core libraries' favorite feature, `@Stable`, to common users!<br>
><br>
> For the API design, however, I have a request: Can we have a <br>
> ComputedConstant factory that creates a List<V> in addition to one <br>
> that creates a List<ComputedConstant<V>>?<br>
><br>
> I think using the List<ComputedConstant<V>> is confusing. The example <br>
> usages in the JEP [1] and in the API specification [2] are already <br>
> wrong: we need an extra ConputedConstant.get() call to unwrap the <br>
> ComputedConstant after List.get(index) call, which currently returns a <br>
> computed constant than the actual value.<br>
><br>
> The current List<ComputedConstant<V>> is to be kept in case users want <br>
> fine-grained control over each constant's resolution failure, etc. and <br>
> covers the new factory's functionality. But I believe the new factory <br>
> will see wider usage:<br>
><br>
> 1. None of the 2 old patterns in the "Motivation" section uses any of <br>
> these exception handling or initialization state detection.<br>
> 2. Returning a List<V> allows users to conveniently pass the list in <br>
> usages instead of using streams or writing custom wrappers.<br>
><br>
> A follow up to a previous request [3], I believe having a map (of type <br>
> Map<K, V> instead of Map<K, ComputedConstant<V>>) would be feasible too.<br>
><br>
> Finally, a side comment about the current <br>
> OnDemandComputedConstantList: it computes ComputedConstant wrappers in <br>
> addition to the actual constants on demand, which... seems a bit <br>
> overkill, when ComputedConstant itself is already a lightweight <br>
> wrapper of a heavy computation?<br>
><br>
> Best,<br>
> Chen Liang<br>
><br>
> [1]: <a href="https://openjdk.org/jeps/8312611" rel="noreferrer" target="_blank">
https://openjdk.org/jeps/8312611</a>  "var kbd = lbl.labels.get(3);"<br>
> [2]: <br>
> <a href="https://cr.openjdk.org/~pminborg/computed-constant/api/java.base/java/lang/ComputedConstant.html#of(int,java.util.function.IntFunction)" rel="noreferrer" target="_blank">
https://cr.openjdk.org/~pminborg/computed-constant/api/java.base/java/lang/ComputedConstant.html#of(int,java.util.function.IntFunction)</a>
<br>
>  "return PO2_CACHE.get(n);"<br>
> [3]: <a href="https://mail.openjdk.org/pipermail/leyden-dev/2023-August/000277.html" rel="noreferrer" target="_blank">
https://mail.openjdk.org/pipermail/leyden-dev/2023-August/000277.html</a></font><br>
</blockquote>
</div>
</div>
</div>
</div>

</div></blockquote></div></div>