1 /*

     2  * Copyright (c) 2008, 2011, Oracle and/or its affiliates. All rights reserved.

     3  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

     4  *

     5  * This code is free software; you can redistribute it and/or modify it

     6  * under the terms of the GNU General Public License version 2 only, as

     7  * published by the Free Software Foundation.  Oracle designates this

     8  * particular file as subject to the "Classpath" exception as provided

     9  * by Oracle in the LICENSE file that accompanied this code.

    10  *

    11  * This code is distributed in the hope that it will be useful, but WITHOUT

    12  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or

    13  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License

    14  * version 2 for more details (a copy is included in the LICENSE file that

    15  * accompanied this code).

    16  *

    17  * You should have received a copy of the GNU General Public License version

    18  * 2 along with this work; if not, write to the Free Software Foundation,

    19  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.

    20  *

    21  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA

    22  * or visit www.oracle.com if you need additional information or have any

    23  * questions.

    24  */

    25 

    26 package java.dyn;

    27 

    28 import sun.dyn.*;

    29 import sun.dyn.empty.Empty;

    30 import java.util.concurrent.atomic.AtomicInteger;

    31 

    32 /**

    33  * A {@code MutableCallSite} is a {@link CallSite} whose target variable

    34  * behaves like an ordinary field.

    35  * An {@code invokedynamic} instruction linked to a {@code MutableCallSite} delegates

    36  * all calls to the site's current target.

    37  * The {@linkplain CallSite#dynamicInvoker dynamic invoker} of a mutable call site

    38  * also delegates each call to the site's current target.

    39  * <p>

    40  * Here is an example of a mutable call site which introduces a

    41  * state variable into a method handle chain.

    42  * <blockquote><pre>

    43 MutableCallSite name = new MutableCallSite(MethodType.methodType(String.class));

    44 MethodHandle MH_name = name.dynamicInvoker();

    45 MethodType MT_str2 = MethodType.methodType(String.class, String.class);

    46 MethodHandle MH_upcase = MethodHandles.lookup()

    47     .findVirtual(String.class, "toUpperCase", MT_str2);

    48 MethodHandle worker1 = MethodHandles.filterReturnValue(MH_name, MH_upcase);

    49 name.setTarget(MethodHandles.constant(String.class, "Rocky"));

    50 assertEquals("ROCKY", (String) worker1.invokeExact());

    51 name.setTarget(MethodHandles.constant(String.class, "Fred"));

    52 assertEquals("FRED", (String) worker1.invokeExact());

    53 // (mutation can be continued indefinitely)

    54  * </pre></blockquote>

    55  * <p>

    56  * The same call site may be used in several places at once.

    57  * <blockquote><pre>

    58 MethodHandle MH_dear = MethodHandles.lookup()

    59     .findVirtual(String.class, "concat", MT_str2).bindTo(", dear?");

    60 MethodHandle worker2 = MethodHandles.filterReturnValue(MH_name, MH_dear);

    61 assertEquals("Fred, dear?", (String) worker2.invokeExact());

    62 name.setTarget(MethodHandles.constant(String.class, "Wilma"));

    63 assertEquals("WILMA", (String) worker1.invokeExact());

    64 assertEquals("Wilma, dear?", (String) worker2.invokeExact());

    65  * </pre></blockquote>

    66  * <p>

    67  * <em>Non-synchronization of target values:</em>

    68  * A write to a mutable call site's target does not force other threads

    69  * to become aware of the updated value.  Threads which do not perform

    70  * suitable synchronization actions relative to the updated call site

    71  * may cache the old target value and delay their use of the new target

    72  * value indefinitely.

    73  * (This is a normal consequence of the Java Memory Model as applied

    74  * to object fields.)

    75  * <p>

    76  * The {@link #syncAll syncAll} operation provides a way to force threads

    77  * to accept a new target value, even if there is no other synchronization.

    78  * <p>

    79  * For target values which will be frequently updated, consider using

    80  * a {@linkplain VolatileCallSite volatile call site} instead.

    81  * @author John Rose, JSR 292 EG

    82  */

    83 public class MutableCallSite extends CallSite {

    84     /**

    85      * Creates a blank call site object with the given method type.

    86      * The initial target is set to a method handle of the given type

    87      * which will throw an {@link IllegalStateException} if called.

    88      * <p>

    89      * The type of the call site is permanently set to the given type.

    90      * <p>

    91      * Before this {@code CallSite} object is returned from a bootstrap method,

    92      * or invoked in some other manner,

    93      * it is usually provided with a more useful target method,

    94      * via a call to {@link CallSite#setTarget(MethodHandle) setTarget}.

    95      * @param type the method type that this call site will have

    96      * @throws NullPointerException if the proposed type is null

    97      */

    98     public MutableCallSite(MethodType type) {

    99         super(type);

   100     }

   101 

   102     /**

   103      * Creates a call site object with an initial target method handle.

   104      * The type of the call site is permanently set to the initial target's type.

   105      * @param target the method handle that will be the initial target of the call site

   106      * @throws NullPointerException if the proposed target is null

   107      */

   108     public MutableCallSite(MethodHandle target) {

   109         super(target);

   110     }

   111 

   112     /**

   113      * Returns the target method of the call site, which behaves

   114      * like a normal field of the {@code MutableCallSite}.

   115      * <p>

   116      * The interactions of {@code getTarget} with memory are the same

   117      * as of a read from an ordinary variable, such as an array element or a

   118      * non-volatile, non-final field.

   119      * <p>

   120      * In particular, the current thread may choose to reuse the result

   121      * of a previous read of the target from memory, and may fail to see

   122      * a recent update to the target by another thread.

   123      *

   124      * @return the linkage state of this call site, a method handle which can change over time

   125      * @see #setTarget

   126      */

   127     @Override public final MethodHandle getTarget() {

   128         return target;

   129     }

   130 

   131     /**

   132      * Updates the target method of this call site, as a normal variable.

   133      * The type of the new target must agree with the type of the old target.

   134      * <p>

   135      * The interactions with memory are the same

   136      * as of a write to an ordinary variable, such as an array element or a

   137      * non-volatile, non-final field.

   138      * <p>

   139      * In particular, unrelated threads may fail to see the updated target

   140      * until they perform a read from memory.

   141      * Stronger guarantees can be created by putting appropriate operations

   142      * into the bootstrap method and/or the target methods used

   143      * at any given call site.

   144      *

   145      * @param newTarget the new target

   146      * @throws NullPointerException if the proposed new target is null

   147      * @throws WrongMethodTypeException if the proposed new target

   148      *         has a method type that differs from the previous target

   149      * @see #getTarget

   150      */

   151     @Override public void setTarget(MethodHandle newTarget) {

   152         checkTargetChange(this.target, newTarget);

   153         setTargetNormal(newTarget);

   154     }

   155 

   156     /**

   157      * {@inheritDoc}

   158      */

   159     @Override

   160     public final MethodHandle dynamicInvoker() {

   161         return makeDynamicInvoker();

   162     }

   163 

   164     /**

   165      * Performs a synchronization operation on each call site in the given array,

   166      * forcing all other threads to throw away any cached values previously

   167      * loaded from the target of any of the call sites.

   168      * <p>

   169      * This operation does not reverse any calls that have already started

   170      * on an old target value.

   171      * (Java supports {@linkplain java.lang.Object#wait() forward time travel} only.)

   172      * <p>

   173      * The overall effect is to force all future readers of each call site's target

   174      * to accept the most recently stored value.

   175      * ("Most recently" is reckoned relative to the {@code syncAll} itself.)

   176      * Conversely, the {@code syncAll} call may block until all readers have

   177      * (somehow) decached all previous versions of each call site's target.

   178      * <p>

   179      * To avoid race conditions, calls to {@code setTarget} and {@code syncAll}

   180      * should generally be performed under some sort of mutual exclusion.

   181      * Note that reader threads may observe an updated target as early

   182      * as the {@code setTarget} call that install the value

   183      * (and before the {@code syncAll} that confirms the value).

   184      * On the other hand, reader threads may observe previous versions of

   185      * the target until the {@code syncAll} call returns

   186      * (and after the {@code setTarget} that attempts to convey the updated version).

   187      * <p>

   188      * This operation is likely to be expensive and should be used sparingly.

   189      * If possible, it should be buffered for batch processing on sets of call sites.

   190      * <p>

   191      * If {@code sites} contains a null element,

   192      * a {@code NullPointerException} will be raised.

   193      * In this case, some non-null elements in the array may be

   194      * processed before the method returns abnormally.

   195      * Which elements these are (if any) is implementation-dependent.

   196      *

   197      * <h3>Java Memory Model details</h3>

   198      * In terms of the Java Memory Model, this operation performs a synchronization

   199      * action which is comparable in effect to the writing of a volatile variable

   200      * by the current thread, and an eventual volatile read by every other thread

   201      * that may access one of the affected call sites.

   202      * <p>

   203      * The following effects are apparent, for each individual call site {@code S}:

   204      * <ul>

   205      * <li>A new volatile variable {@code V} is created, and written by the current thread.

   206      *     As defined by the JMM, this write is a global synchronization event.

   207      * <li>As is normal with thread-local ordering of write events,

   208      *     every action already performed by the current thread is

   209      *     taken to happen before the volatile write to {@code V}.

   210      *     (In some implementations, this means that the current thread

   211      *     performs a global release operation.)

   212      * <li>Specifically, the write to the current target of {@code S} is

   213      *     taken to happen before the volatile write to {@code V}.

   214      * <li>The volatile write to {@code V} is placed

   215      *     (in an implementation specific manner)

   216      *     in the global synchronization order.

   217      * <li>Consider an arbitrary thread {@code T} (other than the current thread).

   218      *     If {@code T} executes a synchronization action {@code A}

   219      *     after the volatile write to {@code V} (in the global synchronization order),

   220      *     it is therefore required to see either the current target

   221      *     of {@code S}, or a later write to that target,

   222      *     if it executes a read on the target of {@code S}.

   223      *     (This constraint is called "synchronization-order consistency".)

   224      * <li>The JMM specifically allows optimizing compilers to elide

   225      *     reads or writes of variables that are known to be useless.

   226      *     Such elided reads and writes have no effect on the happens-before

   227      *     relation.  Regardless of this fact, the volatile {@code V}

   228      *     will not be elided, even though its written value is

   229      *     indeterminate and its read value is not used.

   230      * </ul>

   231      * Because of the last point, the implementation behaves as if a

   232      * volatile read of {@code V} were performed by {@code T}

   233      * immediately after its action {@code A}.  In the local ordering

   234      * of actions in {@code T}, this read happens before any future

   235      * read of the target of {@code S}.  It is as if the

   236      * implementation arbitrarily picked a read of {@code S}'s target

   237      * by {@code T}, and forced a read of {@code V} to precede it,

   238      * thereby ensuring communication of the new target value.

   239      * <p>

   240      * As long as the constraints of the Java Memory Model are obeyed,

   241      * implementations may delay the completion of a {@code syncAll}

   242      * operation while other threads ({@code T} above) continue to

   243      * use previous values of {@code S}'s target.

   244      * However, implementations are (as always) encouraged to avoid

   245      * livelock, and to eventually require all threads to take account

   246      * of the updated target.

   247      *

   248      * <p style="font-size:smaller;">

   249      * <em>Discussion:</em>

   250      * For performance reasons, {@code syncAll} is not a virtual method

   251      * on a single call site, but rather applies to a set of call sites.

   252      * Some implementations may incur a large fixed overhead cost

   253      * for processing one or more synchronization operations,

   254      * but a small incremental cost for each additional call site.

   255      * In any case, this operation is likely to be costly, since

   256      * other threads may have to be somehow interrupted

   257      * in order to make them notice the updated target value.

   258      * However, it may be observed that a single call to synchronize

   259      * several sites has the same formal effect as many calls,

   260      * each on just one of the sites.

   261      *

   262      * <p style="font-size:smaller;">

   263      * <em>Implementation Note:</em>

   264      * Simple implementations of {@code MutableCallSite} may use

   265      * a volatile variable for the target of a mutable call site.

   266      * In such an implementation, the {@code syncAll} method can be a no-op,

   267      * and yet it will conform to the JMM behavior documented above.

   268      *

   269      * @param sites an array of call sites to be synchronized

   270      * @throws NullPointerException if the {@code sites} array reference is null

   271      *                              or the array contains a null

   272      */

   273     public static void syncAll(MutableCallSite[] sites) {

   274         if (sites.length == 0)  return;

   275         STORE_BARRIER.lazySet(0);

   276         for (int i = 0; i < sites.length; i++) {

   277             sites[i].getClass();  // trigger NPE on first null

   278         }

   279         // FIXME: NYI

   280     }

   281     private static final AtomicInteger STORE_BARRIER = new AtomicInteger();

   282 }