<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 28, 2023 at 2:35 PM John Rose <<a href="mailto:john.r.rose@oracle.com">john.r.rose@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">On 28 Jul 2023, at 8:53, Dan Heidinga wrote:<br>
<br>
> … users now need to<br>
> understand if the cost of the lambda generation (inflation?  Not sure what<br>
> the right term is for converting a lambda expression to a functional<br>
> interface instance) will be more or less than the cost of the computation<br>
> they want to store in a ComputedConstant if they want to realize a startup<br>
> benefit from this change.<br>
<br>
Yes, this problem of scaling is raised by the very existence of a better alternative to <clinit>:  Can it beat <clinit> robustly or must it be used sparingly, because the language and VM don’t optimize it very well?<br>
<br>
I would like to take CC’s as they are proposed here, and then expand their mission.  (…After some shallow name changes: package should be java.lang and s/ofList/list/ or s/ofList/of/.)<br>
<br>
After that there are things we can do to reduce their footprint (in cycles and memory, and in user experience), so as to make them much more attractive as an everyday alternative to <clinit>-based fields. </blockquote><div><br></div><div>I'm with you on that goal.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Such “things” might be condensers (as Brian also mentions), </blockquote><div><br></div><div>As much as I want condensers (please, let's get condensers asap!), I'm concerned that features which depend on condensers to get good performance will live in an unstable state unless we can make running condensers so cheap and routine and natural that doing so fits in developers workflows - especially when debugging from within their IDEs.  Features that are painful (and I'm not saying CC's are) at development time, even if great at deployment time, tend to have lower adoption and aren't "sticky" as devs avoid them.</div><div><br></div><div>Unscrambling <clinit> is an essential part of the work Leyden needs to do and CCs are a great step forward on that path.  Now the JVM needs to find a way to routinely optimize them so even uncondensed uses are an obvious choice for developers.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">or maybe language and JVM support.  In any case, the goal would be to help users make a clean escape from the clutches of <clinit>, for the sake of static tools.<br>
<br>
This will be a followup exercise to CC’s.  I’ve written some thoughts about that here, FTR:<br>
<br>
<a href="https://cr.openjdk.org/~jrose/leyden/after-computed-constants.html" rel="noreferrer" target="_blank">https://cr.openjdk.org/~jrose/leyden/after-computed-constants.html</a><br>
<br>
In short:  I think the sweet spot for a condenser target here is not an array of MHs as Brian suggests, but rather a single static method with a string-switch, and a framework for invoking it reflectively from a public BSM of some sort.<br>
<br>
</blockquote></div></div>