178      * (somehow) decached all previous versions of each call site's target.
 179      * <p>
 180      * To avoid race conditions, calls to {@code setTarget} and {@code syncAll}
 181      * should generally be performed under some sort of mutual exclusion.
 182      * Note that reader threads may observe an updated target as early
 183      * as the {@code setTarget} call that install the value
 184      * (and before the {@code syncAll} that confirms the value).
 185      * On the other hand, reader threads may observe previous versions of
 186      * the target until the {@code syncAll} call returns
 187      * (and after the {@code setTarget} that attempts to convey the updated version).
 188      * <p>
 189      * This operation is likely to be expensive and should be used sparingly.
 190      * If possible, it should be buffered for batch processing on sets of call sites.
 191      * <p>
 192      * If {@code sites} contains a null element,
 193      * a {@code NullPointerException} will be raised.
 194      * In this case, some non-null elements in the array may be
 195      * processed before the method returns abnormally.
 196      * Which elements these are (if any) is implementation-dependent.
 197      *
 198      * <h3>Java Memory Model details</h3>
 199      * In terms of the Java Memory Model, this operation performs a synchronization
 200      * action which is comparable in effect to the writing of a volatile variable
 201      * by the current thread, and an eventual volatile read by every other thread
 202      * that may access one of the affected call sites.
 203      * <p>
 204      * The following effects are apparent, for each individual call site {@code S}:
 205      * <ul>
 206      * <li>A new volatile variable {@code V} is created, and written by the current thread.
 207      *     As defined by the JMM, this write is a global synchronization event.
 208      * <li>As is normal with thread-local ordering of write events,
 209      *     every action already performed by the current thread is
 210      *     taken to happen before the volatile write to {@code V}.
 211      *     (In some implementations, this means that the current thread
 212      *     performs a global release operation.)
 213      * <li>Specifically, the write to the current target of {@code S} is
 214      *     taken to happen before the volatile write to {@code V}.
 215      * <li>The volatile write to {@code V} is placed
 216      *     (in an implementation specific manner)
 217      *     in the global synchronization order.
 218      * <li>Consider an arbitrary thread {@code T} (other than the current thread).

 178      * (somehow) decached all previous versions of each call site's target.
 179      * <p>
 180      * To avoid race conditions, calls to {@code setTarget} and {@code syncAll}
 181      * should generally be performed under some sort of mutual exclusion.
 182      * Note that reader threads may observe an updated target as early
 183      * as the {@code setTarget} call that install the value
 184      * (and before the {@code syncAll} that confirms the value).
 185      * On the other hand, reader threads may observe previous versions of
 186      * the target until the {@code syncAll} call returns
 187      * (and after the {@code setTarget} that attempts to convey the updated version).
 188      * <p>
 189      * This operation is likely to be expensive and should be used sparingly.
 190      * If possible, it should be buffered for batch processing on sets of call sites.
 191      * <p>
 192      * If {@code sites} contains a null element,
 193      * a {@code NullPointerException} will be raised.
 194      * In this case, some non-null elements in the array may be
 195      * processed before the method returns abnormally.
 196      * Which elements these are (if any) is implementation-dependent.
 197      *
 198      * <h1>Java Memory Model details</h1>
 199      * In terms of the Java Memory Model, this operation performs a synchronization
 200      * action which is comparable in effect to the writing of a volatile variable
 201      * by the current thread, and an eventual volatile read by every other thread
 202      * that may access one of the affected call sites.
 203      * <p>
 204      * The following effects are apparent, for each individual call site {@code S}:
 205      * <ul>
 206      * <li>A new volatile variable {@code V} is created, and written by the current thread.
 207      *     As defined by the JMM, this write is a global synchronization event.
 208      * <li>As is normal with thread-local ordering of write events,
 209      *     every action already performed by the current thread is
 210      *     taken to happen before the volatile write to {@code V}.
 211      *     (In some implementations, this means that the current thread
 212      *     performs a global release operation.)
 213      * <li>Specifically, the write to the current target of {@code S} is
 214      *     taken to happen before the volatile write to {@code V}.
 215      * <li>The volatile write to {@code V} is placed
 216      *     (in an implementation specific manner)
 217      *     in the global synchronization order.
 218      * <li>Consider an arbitrary thread {@code T} (other than the current thread).