RFR: 8283237: CallSite should be a sealed class

[Rémi Forax]

On Thu, 17 Mar 2022 07:32:40 GMT, liach <duke at openjdk.java.net> wrote:

>> src/java.base/share/classes/java/lang/invoke/CallSite.java line 88:
>> 
>>> 86:  */
>>> 87: public
>>> 88: abstract sealed class CallSite permits ConstantCallSite, VolatileCallSite, MutableCallSite {
>> 
>> Nitpicking with my JSR 292 hat,
>> given that the permits clause is reflected in the javadoc,
>> the order should be ConstantCS, MutableCS and VolatileCS,
>> it's both in the lexical order and in the "memory access" of setTarget() order , from stronger access to weaker access.
>
> I agree that Constant, Mutable, Volatile order is better, ranked by the respective cost for `setTarget()` and (possibly) invocation, and earlier ones in the list are more preferable if conditions allow.
> 
> However, in the current API documentation, the order is Constant, Mutable, and Volatile. Should I update that or leave it?
> 
> /*
>  * <ul>
>  * <li>If a mutable target is not required, an {@code invokedynamic} instruction
>  * may be permanently bound by means of a {@linkplain ConstantCallSite constant call site}.
>  * <li>If a mutable target is required which has volatile variable semantics,
>  * because updates to the target must be immediately and reliably witnessed by other threads,
>  * a {@linkplain VolatileCallSite volatile call site} may be used.
>  * <li>Otherwise, if a mutable target is required,
>  * a {@linkplain MutableCallSite mutable call site} may be used.
>  * </ul>
>  */

For me, this is unrelated, for this paragraph it's easier to explain the semantics of MutableCallSite with an otherwise, i.e. it's mutable but you do not want the cost of a volatile acces.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7840