RFR: 8283237: CallSite should be a sealed class

[liach]

On Thu, 17 Mar 2022 06:47:13 GMT, Rémi Forax <forax at openjdk.org> wrote:

>> Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me.
>
> 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>
 */

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

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