*       allocating garbage).
 * </ul>
 *
 * <p>Disadvantages compared to {@code double[]}:
 *
 * <ul>
 *   <li>Memory footprint has a fixed overhead (about 24 bytes per instance).
 *   <li><i>Some</i> construction use cases force the data to be copied (though several construction
 *       APIs are offered that don't).

 * general way.
 *
 * <p>A good example of usage of this class is for HTML escaping where the replacement array
 * contains information about the named HTML entities such as {@code &amp;} and {@code &quot;} while
 * {@link #escapeUnsafe} is overridden to handle general escaping of the form {@code &#NNNNN;}.
 *

     * hopefully could avoid implementing Entry or ValueSetLink at all. (But note that that approach
     * requires us to define extra classes -- unfortunate under Android.) *Then* we could consider
     * lying about the fields below on the grounds that we always initialize them just after the
     * constructor -- an example of the kind of lying that our hypothetical bytecode rewriter would

                   */
                  Set<Integer> unused = graph.successors(first);
                  return null;
                }
              }));
    }

    // For more about this test, see the equivalent in AbstractNetworkTest.
    for (Future<?> future : futures.build()) {
      future.get();
    }
    executor.shutdown();
  }

     * inputs, rather than as if it never tolerates them.
     *
     * We rely on checkers to implement special cases to catch dangerous calls to join(), etc. based
     * on what they know about the particular Joiner instances the calls are performed on.
     *
     * (In addition to useForNull, we also offer skipNulls. It, too, tolerates null inputs, but its

         * Therefore, we can always create our own TypeVariable.
         *
         * 2. Starting with JDK 7u51, the JDK TypeVariable implementations does not interoperate
         * with ours. Therefore, we have to be careful about whether we create our own TypeVariable:
         *
         * 2a. If the resolved types are identical to the original types, then we can return the

 *   <li>The documentation style for testcases is to provide as javadoc a simple sentence or two
 *       describing the property that the testcase method purports to test. The javadocs do not say
 *       anything about how the property is tested. To find out, read the code.
 *   <li>These tests are "conformance tests", and do not attempt to test throughput, latency,

      for (LockGraphNode acquiredLock : acquiredLocks) {
        checkAcquiredLock(policy, acquiredLock);
      }
    }

    /**
     * Checks the acquisition-ordering between {@code this}, which is about to be acquired, and the
     * specified {@code acquiredLock}.
     *
     * <p>When this method returns, the {@code acquiredLock} should be in either the {@code

 * indexes} is generally less than the total time taken to compute each of them separately, and
 * sometimes much less. For example, on a large enough dataset, computing the 90th and 99th
 * percentiles together takes about 55% as long as computing them separately.
 *
 * <p>When calling {@link ScaleAndIndex#compute} (in {@linkplain ScaleAndIndexes#compute either

     */
    /*
     * TODO(cpovirk): use Object[] instead of E[] in the mainline? (The backport is different and
     * doesn't need this suppression, but we keep it to minimize diffs.) Generally be more clear
     * about when we have an Object[] vs. a Comparable[] or other array type in internalArray? If we
     * used Object[], we might be able to optimize toArray() to use clone() sometimes. (See
     * cl/592273615 and cl/592273683.)
     */