Draft JEP Announcement: "Computed Constants"

[Brian Goetz]

On 7/28/2023 11:53 AM, Dan Heidinga wrote:
>
> With my "optimizing startup hat on", I share some of the concerns 
> others have expressed about the use of lambdas to initialize 
> ComputedConstant as it exposes the lambda cost model to end users - 
> users now need to understand if the cost of the lambda generation 
> (inflation?  Not sure what the right term is for converting a lambda 
> expression to a functional interface instance) will be more or less 
> than the cost of the computation they want to store in a 
> ComputedConstant if they want to realize a startup benefit from this 
> change.

I share the concern, though I think we can address that as a separate 
follow-on topic.

Given a computed constant

     public static final ComputedConstant<String> swellGuy = 
ComputedConstant.of(() -> "Dan");

the lambda `() -> "Dan"` is likely to be fairly constrained.  It is 
unlikely to be aliased, it is only going to be called once, it doesn't 
capture any state from the lexical environment, etc.  A condenser could 
easily refactor this (assuming the above constraints are observed to be 
true) to move the body `{ return "Dan"; }` to a private static method in 
the same class, and rewrite the CC declaration to

     ... = ComputedConstant.of( Constant_MethodHandle[private method] );

This eliminates the proxy class / anon class.  The CC API can be 
designed in such a way to permit such lowerings, and paired with a 
condenser that understands the necessarily constraints (a MH overload 
factory is entirely reasonable.)

A separate condenser might pre-resolve the MH constant and put it in the 
CDS archive, on the observation that it may be needed early.

> As suggested in the "Dependencies" section of the JEP, this may enable 
> pre-evaluating computed constants.  Given that goal, should language 
> like the following sentence from the java.util.concurrent.constant 
> package summary javadoc be avoid?
> > In other words, a provider can only run once and in the 
> first-calling thread and so, there is no race across threads which 
> guarantees the at-most-once evaluation
> This defines when the provider is called which may need to be adapted 
> if time-shifting a ComputedConstant becomes possible.  Is it better to 
> avoid the "first-calling thread" claim from the start?

Yes, I think this was probably a leftover from an earlier draft. The 
sensible constraint is "no later than first use", leaving early 
initialization wide open to be specified by a separate mechanism.