1.1 --- a/rt/emul/compact/src/main/java/java/lang/invoke/MutableCallSite.java Sun Aug 17 20:09:05 2014 +0200
1.2 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000
1.3 @@ -1,283 +0,0 @@
1.4 -/*
1.5 - * Copyright (c) 2008, 2013, Oracle and/or its affiliates. All rights reserved.
1.6 - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
1.7 - *
1.8 - * This code is free software; you can redistribute it and/or modify it
1.9 - * under the terms of the GNU General Public License version 2 only, as
1.10 - * published by the Free Software Foundation. Oracle designates this
1.11 - * particular file as subject to the "Classpath" exception as provided
1.12 - * by Oracle in the LICENSE file that accompanied this code.
1.13 - *
1.14 - * This code is distributed in the hope that it will be useful, but WITHOUT
1.15 - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
1.16 - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
1.17 - * version 2 for more details (a copy is included in the LICENSE file that
1.18 - * accompanied this code).
1.19 - *
1.20 - * You should have received a copy of the GNU General Public License version
1.21 - * 2 along with this work; if not, write to the Free Software Foundation,
1.22 - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
1.23 - *
1.24 - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
1.25 - * or visit www.oracle.com if you need additional information or have any
1.26 - * questions.
1.27 - */
1.28 -
1.29 -package java.lang.invoke;
1.30 -
1.31 -import java.util.concurrent.atomic.AtomicInteger;
1.32 -
1.33 -/**
1.34 - * A {@code MutableCallSite} is a {@link CallSite} whose target variable
1.35 - * behaves like an ordinary field.
1.36 - * An {@code invokedynamic} instruction linked to a {@code MutableCallSite} delegates
1.37 - * all calls to the site's current target.
1.38 - * The {@linkplain CallSite#dynamicInvoker dynamic invoker} of a mutable call site
1.39 - * also delegates each call to the site's current target.
1.40 - * <p>
1.41 - * Here is an example of a mutable call site which introduces a
1.42 - * state variable into a method handle chain.
1.43 - * <!-- JavaDocExamplesTest.testMutableCallSite -->
1.44 - * <blockquote><pre>{@code
1.45 -MutableCallSite name = new MutableCallSite(MethodType.methodType(String.class));
1.46 -MethodHandle MH_name = name.dynamicInvoker();
1.47 -MethodType MT_str1 = MethodType.methodType(String.class);
1.48 -MethodHandle MH_upcase = MethodHandles.lookup()
1.49 - .findVirtual(String.class, "toUpperCase", MT_str1);
1.50 -MethodHandle worker1 = MethodHandles.filterReturnValue(MH_name, MH_upcase);
1.51 -name.setTarget(MethodHandles.constant(String.class, "Rocky"));
1.52 -assertEquals("ROCKY", (String) worker1.invokeExact());
1.53 -name.setTarget(MethodHandles.constant(String.class, "Fred"));
1.54 -assertEquals("FRED", (String) worker1.invokeExact());
1.55 -// (mutation can be continued indefinitely)
1.56 - * }</pre></blockquote>
1.57 - * <p>
1.58 - * The same call site may be used in several places at once.
1.59 - * <blockquote><pre>{@code
1.60 -MethodType MT_str2 = MethodType.methodType(String.class, String.class);
1.61 -MethodHandle MH_cat = lookup().findVirtual(String.class,
1.62 - "concat", methodType(String.class, String.class));
1.63 -MethodHandle MH_dear = MethodHandles.insertArguments(MH_cat, 1, ", dear?");
1.64 -MethodHandle worker2 = MethodHandles.filterReturnValue(MH_name, MH_dear);
1.65 -assertEquals("Fred, dear?", (String) worker2.invokeExact());
1.66 -name.setTarget(MethodHandles.constant(String.class, "Wilma"));
1.67 -assertEquals("WILMA", (String) worker1.invokeExact());
1.68 -assertEquals("Wilma, dear?", (String) worker2.invokeExact());
1.69 - * }</pre></blockquote>
1.70 - * <p>
1.71 - * <em>Non-synchronization of target values:</em>
1.72 - * A write to a mutable call site's target does not force other threads
1.73 - * to become aware of the updated value. Threads which do not perform
1.74 - * suitable synchronization actions relative to the updated call site
1.75 - * may cache the old target value and delay their use of the new target
1.76 - * value indefinitely.
1.77 - * (This is a normal consequence of the Java Memory Model as applied
1.78 - * to object fields.)
1.79 - * <p>
1.80 - * The {@link #syncAll syncAll} operation provides a way to force threads
1.81 - * to accept a new target value, even if there is no other synchronization.
1.82 - * <p>
1.83 - * For target values which will be frequently updated, consider using
1.84 - * a {@linkplain VolatileCallSite volatile call site} instead.
1.85 - * @author John Rose, JSR 292 EG
1.86 - */
1.87 -public class MutableCallSite extends CallSite {
1.88 - /**
1.89 - * Creates a blank call site object with the given method type.
1.90 - * The initial target is set to a method handle of the given type
1.91 - * which will throw an {@link IllegalStateException} if called.
1.92 - * <p>
1.93 - * The type of the call site is permanently set to the given type.
1.94 - * <p>
1.95 - * Before this {@code CallSite} object is returned from a bootstrap method,
1.96 - * or invoked in some other manner,
1.97 - * it is usually provided with a more useful target method,
1.98 - * via a call to {@link CallSite#setTarget(MethodHandle) setTarget}.
1.99 - * @param type the method type that this call site will have
1.100 - * @throws NullPointerException if the proposed type is null
1.101 - */
1.102 - public MutableCallSite(MethodType type) {
1.103 - super(type);
1.104 - }
1.105 -
1.106 - /**
1.107 - * Creates a call site object with an initial target method handle.
1.108 - * The type of the call site is permanently set to the initial target's type.
1.109 - * @param target the method handle that will be the initial target of the call site
1.110 - * @throws NullPointerException if the proposed target is null
1.111 - */
1.112 - public MutableCallSite(MethodHandle target) {
1.113 - super(target);
1.114 - }
1.115 -
1.116 - /**
1.117 - * Returns the target method of the call site, which behaves
1.118 - * like a normal field of the {@code MutableCallSite}.
1.119 - * <p>
1.120 - * The interactions of {@code getTarget} with memory are the same
1.121 - * as of a read from an ordinary variable, such as an array element or a
1.122 - * non-volatile, non-final field.
1.123 - * <p>
1.124 - * In particular, the current thread may choose to reuse the result
1.125 - * of a previous read of the target from memory, and may fail to see
1.126 - * a recent update to the target by another thread.
1.127 - *
1.128 - * @return the linkage state of this call site, a method handle which can change over time
1.129 - * @see #setTarget
1.130 - */
1.131 - @Override public final MethodHandle getTarget() {
1.132 - return target;
1.133 - }
1.134 -
1.135 - /**
1.136 - * Updates the target method of this call site, as a normal variable.
1.137 - * The type of the new target must agree with the type of the old target.
1.138 - * <p>
1.139 - * The interactions with memory are the same
1.140 - * as of a write to an ordinary variable, such as an array element or a
1.141 - * non-volatile, non-final field.
1.142 - * <p>
1.143 - * In particular, unrelated threads may fail to see the updated target
1.144 - * until they perform a read from memory.
1.145 - * Stronger guarantees can be created by putting appropriate operations
1.146 - * into the bootstrap method and/or the target methods used
1.147 - * at any given call site.
1.148 - *
1.149 - * @param newTarget the new target
1.150 - * @throws NullPointerException if the proposed new target is null
1.151 - * @throws WrongMethodTypeException if the proposed new target
1.152 - * has a method type that differs from the previous target
1.153 - * @see #getTarget
1.154 - */
1.155 - @Override public void setTarget(MethodHandle newTarget) {
1.156 - checkTargetChange(this.target, newTarget);
1.157 - setTargetNormal(newTarget);
1.158 - }
1.159 -
1.160 - /**
1.161 - * {@inheritDoc}
1.162 - */
1.163 - @Override
1.164 - public final MethodHandle dynamicInvoker() {
1.165 - return makeDynamicInvoker();
1.166 - }
1.167 -
1.168 - /**
1.169 - * Performs a synchronization operation on each call site in the given array,
1.170 - * forcing all other threads to throw away any cached values previously
1.171 - * loaded from the target of any of the call sites.
1.172 - * <p>
1.173 - * This operation does not reverse any calls that have already started
1.174 - * on an old target value.
1.175 - * (Java supports {@linkplain java.lang.Object#wait() forward time travel} only.)
1.176 - * <p>
1.177 - * The overall effect is to force all future readers of each call site's target
1.178 - * to accept the most recently stored value.
1.179 - * ("Most recently" is reckoned relative to the {@code syncAll} itself.)
1.180 - * Conversely, the {@code syncAll} call may block until all readers have
1.181 - * (somehow) decached all previous versions of each call site's target.
1.182 - * <p>
1.183 - * To avoid race conditions, calls to {@code setTarget} and {@code syncAll}
1.184 - * should generally be performed under some sort of mutual exclusion.
1.185 - * Note that reader threads may observe an updated target as early
1.186 - * as the {@code setTarget} call that install the value
1.187 - * (and before the {@code syncAll} that confirms the value).
1.188 - * On the other hand, reader threads may observe previous versions of
1.189 - * the target until the {@code syncAll} call returns
1.190 - * (and after the {@code setTarget} that attempts to convey the updated version).
1.191 - * <p>
1.192 - * This operation is likely to be expensive and should be used sparingly.
1.193 - * If possible, it should be buffered for batch processing on sets of call sites.
1.194 - * <p>
1.195 - * If {@code sites} contains a null element,
1.196 - * a {@code NullPointerException} will be raised.
1.197 - * In this case, some non-null elements in the array may be
1.198 - * processed before the method returns abnormally.
1.199 - * Which elements these are (if any) is implementation-dependent.
1.200 - *
1.201 - * <h1>Java Memory Model details</h1>
1.202 - * In terms of the Java Memory Model, this operation performs a synchronization
1.203 - * action which is comparable in effect to the writing of a volatile variable
1.204 - * by the current thread, and an eventual volatile read by every other thread
1.205 - * that may access one of the affected call sites.
1.206 - * <p>
1.207 - * The following effects are apparent, for each individual call site {@code S}:
1.208 - * <ul>
1.209 - * <li>A new volatile variable {@code V} is created, and written by the current thread.
1.210 - * As defined by the JMM, this write is a global synchronization event.
1.211 - * <li>As is normal with thread-local ordering of write events,
1.212 - * every action already performed by the current thread is
1.213 - * taken to happen before the volatile write to {@code V}.
1.214 - * (In some implementations, this means that the current thread
1.215 - * performs a global release operation.)
1.216 - * <li>Specifically, the write to the current target of {@code S} is
1.217 - * taken to happen before the volatile write to {@code V}.
1.218 - * <li>The volatile write to {@code V} is placed
1.219 - * (in an implementation specific manner)
1.220 - * in the global synchronization order.
1.221 - * <li>Consider an arbitrary thread {@code T} (other than the current thread).
1.222 - * If {@code T} executes a synchronization action {@code A}
1.223 - * after the volatile write to {@code V} (in the global synchronization order),
1.224 - * it is therefore required to see either the current target
1.225 - * of {@code S}, or a later write to that target,
1.226 - * if it executes a read on the target of {@code S}.
1.227 - * (This constraint is called "synchronization-order consistency".)
1.228 - * <li>The JMM specifically allows optimizing compilers to elide
1.229 - * reads or writes of variables that are known to be useless.
1.230 - * Such elided reads and writes have no effect on the happens-before
1.231 - * relation. Regardless of this fact, the volatile {@code V}
1.232 - * will not be elided, even though its written value is
1.233 - * indeterminate and its read value is not used.
1.234 - * </ul>
1.235 - * Because of the last point, the implementation behaves as if a
1.236 - * volatile read of {@code V} were performed by {@code T}
1.237 - * immediately after its action {@code A}. In the local ordering
1.238 - * of actions in {@code T}, this read happens before any future
1.239 - * read of the target of {@code S}. It is as if the
1.240 - * implementation arbitrarily picked a read of {@code S}'s target
1.241 - * by {@code T}, and forced a read of {@code V} to precede it,
1.242 - * thereby ensuring communication of the new target value.
1.243 - * <p>
1.244 - * As long as the constraints of the Java Memory Model are obeyed,
1.245 - * implementations may delay the completion of a {@code syncAll}
1.246 - * operation while other threads ({@code T} above) continue to
1.247 - * use previous values of {@code S}'s target.
1.248 - * However, implementations are (as always) encouraged to avoid
1.249 - * livelock, and to eventually require all threads to take account
1.250 - * of the updated target.
1.251 - *
1.252 - * <p style="font-size:smaller;">
1.253 - * <em>Discussion:</em>
1.254 - * For performance reasons, {@code syncAll} is not a virtual method
1.255 - * on a single call site, but rather applies to a set of call sites.
1.256 - * Some implementations may incur a large fixed overhead cost
1.257 - * for processing one or more synchronization operations,
1.258 - * but a small incremental cost for each additional call site.
1.259 - * In any case, this operation is likely to be costly, since
1.260 - * other threads may have to be somehow interrupted
1.261 - * in order to make them notice the updated target value.
1.262 - * However, it may be observed that a single call to synchronize
1.263 - * several sites has the same formal effect as many calls,
1.264 - * each on just one of the sites.
1.265 - *
1.266 - * <p style="font-size:smaller;">
1.267 - * <em>Implementation Note:</em>
1.268 - * Simple implementations of {@code MutableCallSite} may use
1.269 - * a volatile variable for the target of a mutable call site.
1.270 - * In such an implementation, the {@code syncAll} method can be a no-op,
1.271 - * and yet it will conform to the JMM behavior documented above.
1.272 - *
1.273 - * @param sites an array of call sites to be synchronized
1.274 - * @throws NullPointerException if the {@code sites} array reference is null
1.275 - * or the array contains a null
1.276 - */
1.277 - public static void syncAll(MutableCallSite[] sites) {
1.278 - if (sites.length == 0) return;
1.279 - STORE_BARRIER.lazySet(0);
1.280 - for (int i = 0; i < sites.length; i++) {
1.281 - sites[i].getClass(); // trigger NPE on first null
1.282 - }
1.283 - // FIXME: NYI
1.284 - }
1.285 - private static final AtomicInteger STORE_BARRIER = new AtomicInteger();
1.286 -}