On Thu, 17 Mar 2022 07:32:40 GMT, liach <d...@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
