SwitchPoint.java 10.7 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
/*
 * Copyright (c) 2010, 2011, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.  Oracle designates this
 * particular file as subject to the "Classpath" exception as provided
 * by Oracle in the LICENSE file that accompanied this code.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

26
package java.lang.invoke;
27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59

/**
 * <p>
 * A {@code SwitchPoint} is an object which can publish state transitions to other threads.
 * A switch point is initially in the <em>valid</em> state, but may at any time be
 * changed to the <em>invalid</em> state.  Invalidation cannot be reversed.
 * A switch point can combine a <em>guarded pair</em> of method handles into a
 * <em>guarded delegator</em>.
 * The guarded delegator is a method handle which delegates to one of the old method handles.
 * The state of the switch point determines which of the two gets the delegation.
 * <p>
 * A single switch point may be used to control any number of method handles.
 * (Indirectly, therefore, it can control any number of call sites.)
 * This is done by using the single switch point as a factory for combining
 * any number of guarded method handle pairs into guarded delegators.
 * <p>
 * When a guarded delegator is created from a guarded pair, the pair
 * is wrapped in a new method handle {@code M},
 * which is permanently associated with the switch point that created it.
 * Each pair consists of a target {@code T} and a fallback {@code F}.
 * While the switch point is valid, invocations to {@code M} are delegated to {@code T}.
 * After it is invalidated, invocations are delegated to {@code F}.
 * <p>
 * Invalidation is global and immediate, as if the switch point contained a
 * volatile boolean variable consulted on every call to {@code M}.
 * The invalidation is also permanent, which means the switch point
 * can change state only once.
 * The switch point will always delegate to {@code F} after being invalidated.
 * At that point {@code guardWithTest} may ignore {@code T} and return {@code F}.
 * <p>
 * Here is an example of a switch point in action:
 * <blockquote><pre>
MethodHandle MH_strcat = MethodHandles.lookup()
60
    .findVirtual(String.class, "concat", MethodType.methodType(String.class, String.class));
61
SwitchPoint spt = new SwitchPoint();
62
assert(!spt.hasBeenInvalidated());
63
// the following steps may be repeated to re-use the same switch point:
64 65
MethodHandle worker1 = MH_strcat;
MethodHandle worker2 = MethodHandles.permuteArguments(MH_strcat, MH_strcat.type(), 1, 0);
66 67 68
MethodHandle worker = spt.guardWithTest(worker1, worker2);
assertEquals("method", (String) worker.invokeExact("met", "hod"));
SwitchPoint.invalidateAll(new SwitchPoint[]{ spt });
69
assert(spt.hasBeenInvalidated());
70 71 72 73 74 75 76
assertEquals("hodmet", (String) worker.invokeExact("met", "hod"));
 * </pre></blockquote>
 * <p style="font-size:smaller;">
 * <em>Discussion:</em>
 * Switch points are useful without subclassing.  They may also be subclassed.
 * This may be useful in order to associate application-specific invalidation logic
 * with the switch point.
77 78 79 80
 * Notice that there is no permanent association between a switch point and
 * the method handles it produces and consumes.
 * The garbage collector may collect method handles produced or consumed
 * by a switch point independently of the lifetime of the switch point itself.
81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127
 * <p style="font-size:smaller;">
 * <em>Implementation Note:</em>
 * A switch point behaves as if implemented on top of {@link MutableCallSite},
 * approximately as follows:
 * <blockquote><pre>
public class SwitchPoint {
  private static final MethodHandle
    K_true  = MethodHandles.constant(boolean.class, true),
    K_false = MethodHandles.constant(boolean.class, false);
  private final MutableCallSite mcs;
  private final MethodHandle mcsInvoker;
  public SwitchPoint() {
    this.mcs = new MutableCallSite(K_true);
    this.mcsInvoker = mcs.dynamicInvoker();
  }
  public MethodHandle guardWithTest(
                MethodHandle target, MethodHandle fallback) {
    // Note:  mcsInvoker is of type ()boolean.
    // Target and fallback may take any arguments, but must have the same type.
    return MethodHandles.guardWithTest(this.mcsInvoker, target, fallback);
  }
  public static void invalidateAll(SwitchPoint[] spts) {
    List&lt;MutableCallSite&gt; mcss = new ArrayList&lt;&gt;();
    for (SwitchPoint spt : spts)  mcss.add(spt.mcs);
    for (MutableCallSite mcs : mcss)  mcs.setTarget(K_false);
    MutableCallSite.syncAll(mcss.toArray(new MutableCallSite[0]));
  }
}
 * </pre></blockquote>
 * @author Remi Forax, JSR 292 EG
 */
public class SwitchPoint {
    private static final MethodHandle
        K_true  = MethodHandles.constant(boolean.class, true),
        K_false = MethodHandles.constant(boolean.class, false);

    private final MutableCallSite mcs;
    private final MethodHandle mcsInvoker;

    /**
     * Creates a new switch point.
     */
    public SwitchPoint() {
        this.mcs = new MutableCallSite(K_true);
        this.mcsInvoker = mcs.dynamicInvoker();
    }

128
    /**
129 130 131 132 133 134 135 136 137 138
     * Determines if this switch point has been invalidated yet.
     *
     * <p style="font-size:smaller;">
     * <em>Discussion:</em>
     * Because of the one-way nature of invalidation, once a switch point begins
     * to return true for {@code hasBeenInvalidated},
     * it will always do so in the future.
     * On the other hand, a valid switch point visible to other threads may
     * invalidated at any moment, due to a request by another thread.
     * <p style="font-size:smaller;">
139
     * Since invalidation is a global and immediate operation,
140 141 142 143 144 145 146 147 148 149
     * the execution of this query, on a valid switchpoint,
     * must be internally sequenced with any
     * other threads that could cause invalidation.
     * This query may therefore be expensive.
     * The recommended way to build a boolean-valued method handle
     * which queries the invalidation state of a switch point {@code s} is
     * to call {@code s.guardWithTest} on
     * {@link MethodHandles#constant constant} true and false method handles.
     *
     * @return true if this switch point has been invalidated
150
     */
151 152
    public boolean hasBeenInvalidated() {
        return (mcs.getTarget() != K_true);
153 154
    }

155 156 157 158 159 160 161 162 163 164 165 166
    /**
     * Returns a method handle which always delegates either to the target or the fallback.
     * The method handle will delegate to the target exactly as long as the switch point is valid.
     * After that, it will permanently delegate to the fallback.
     * <p>
     * The target and fallback must be of exactly the same method type,
     * and the resulting combined method handle will also be of this type.
     *
     * @param target the method handle selected by the switch point as long as it is valid
     * @param fallback the method handle selected by the switch point after it is invalidated
     * @return a combined method handle which always calls either the target or fallback
     * @throws NullPointerException if either argument is null
167
     * @throws IllegalArgumentException if the two method types do not match
168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228
     * @see MethodHandles#guardWithTest
     */
    public MethodHandle guardWithTest(MethodHandle target, MethodHandle fallback) {
        if (mcs.getTarget() == K_false)
            return fallback;  // already invalid
        return MethodHandles.guardWithTest(mcsInvoker, target, fallback);
    }

    /**
     * Sets all of the given switch points into the invalid state.
     * After this call executes, no thread will observe any of the
     * switch points to be in a valid state.
     * <p>
     * This operation is likely to be expensive and should be used sparingly.
     * If possible, it should be buffered for batch processing on sets of switch points.
     * <p>
     * If {@code switchPoints} contains a null element,
     * a {@code NullPointerException} will be raised.
     * In this case, some non-null elements in the array may be
     * processed before the method returns abnormally.
     * Which elements these are (if any) is implementation-dependent.
     *
     * <p style="font-size:smaller;">
     * <em>Discussion:</em>
     * For performance reasons, {@code invalidateAll} is not a virtual method
     * on a single switch point, but rather applies to a set of switch points.
     * Some implementations may incur a large fixed overhead cost
     * for processing one or more invalidation operations,
     * but a small incremental cost for each additional invalidation.
     * In any case, this operation is likely to be costly, since
     * other threads may have to be somehow interrupted
     * in order to make them notice the updated switch point state.
     * However, it may be observed that a single call to invalidate
     * several switch points has the same formal effect as many calls,
     * each on just one of the switch points.
     *
     * <p style="font-size:smaller;">
     * <em>Implementation Note:</em>
     * Simple implementations of {@code SwitchPoint} may use
     * a private {@link MutableCallSite} to publish the state of a switch point.
     * In such an implementation, the {@code invalidateAll} method can
     * simply change the call site's target, and issue one call to
     * {@linkplain MutableCallSite#syncAll synchronize} all the
     * private call sites.
     *
     * @param switchPoints an array of call sites to be synchronized
     * @throws NullPointerException if the {@code switchPoints} array reference is null
     *                              or the array contains a null
     */
    public static void invalidateAll(SwitchPoint[] switchPoints) {
        if (switchPoints.length == 0)  return;
        MutableCallSite[] sites = new MutableCallSite[switchPoints.length];
        for (int i = 0; i < switchPoints.length; i++) {
            SwitchPoint spt = switchPoints[i];
            if (spt == null)  break;  // MSC.syncAll will trigger a NPE
            sites[i] = spt.mcs;
            spt.mcs.setTarget(K_false);
        }
        MutableCallSite.syncAll(sites);
    }
}