/** All listeners. */
  volatile @Nullable Listener listenersField;

  /** All waiting threads. */
  volatile @Nullable Waiter waitersField;

  /** Non-volatile write of the thread to the {@link Waiter#thread} field. */
  private static void putThread(Waiter waiter, Thread newValue) {
    ATOMIC_HELPER.putThread(waiter, newValue);
  }

     * as well as to handle state changes in a thread-safe manner. The current state of the future
     * is held in the Sync state, and the lock is released whenever the state changes to {@link
     * #COMPLETED}, {@link #CANCELLED}, or {@link #INTERRUPTED}
     *
     * <p>To avoid races between threads doing release and acquire, we transition to the final state

  }

  public void testNegativeTimeout() throws Exception {
    future.set(1);
    assertEquals(1, future.get(-1, SECONDS).intValue());
  }

  @J2ktIncompatible
  @GwtIncompatible // threads
  public void testOverflowTimeout() throws Exception {
    // First, sanity check that naive multiplication would really overflow to a negative number:
    long nanosPerSecond = NANOSECONDS.convert(1, SECONDS);

        engine.close();
    }

    // ===== Concurrent Evaluation Tests =====

    /**
     * Test concurrent evaluation of the same script from multiple threads
     */
    @Test
    public void test_evaluate_concurrentSameScript() throws Exception {
        final GroovyEngine engine = new GroovyEngine();
        final int threadCount = 8;

crawler.system.monitor.interval=60
# Whether to ignore idle threads in hot thread monitoring.
crawler.hotthread.ignore_idle_threads=true
# Interval for hot thread monitoring (e.g., 500ms).
crawler.hotthread.interval=500ms
# Number of snapshots for hot thread monitoring.
crawler.hotthread.snapshots=10
# Number of threads for hot thread monitoring.
crawler.hotthread.threads=3
# Timeout for hot thread monitoring (e.g., 30s).
crawler.hotthread.timeout=30s

   * accommodate as many threads as will ever concurrently modify the table. Using a significantly
   * higher value than you need can waste space and time, and a significantly lower value can lead
   * to thread contention. But overestimates and underestimates within an order of magnitude do not
   * usually have much noticeable impact. A value of one permits only one thread to modify the cache

      return true;
    }

    boolean get(long bitIndex) {
      return (data.get((int) (bitIndex >>> LONG_ADDRESSABLE_BITS)) & (1L << bitIndex)) != 0;
    }

    /**
     * Careful here: if threads are mutating the atomicLongArray while this method is executing, the
     * final long[] will be a "rolling snapshot" of the state of the bit array. This is usually good
     * enough, but should be kept in mind.
     */

     * until we send the frame that acknowledges this new size.
     *
     * Since we can't ACK settings on the current reader thread (the reader thread can't write) we
     * execute all peer settings logic on the writer thread. This relies on the fact that the
     * writer task queue won't reorder tasks; otherwise settings could be applied in the opposite
     * order than received.
     */

 * since an iteration across all row keys occurs.
 *
 * <p>Note that this implementation is not synchronized. If multiple threads access this table
 * concurrently and one of the threads modifies the table, it must be synchronized externally.
 *
 * @author Jared Levy
 */
@GwtCompatible
class StandardTable<R, C, V> extends AbstractTable<R, C, V> implements Serializable {

    //
    // TODO(user): Consider using
    // java/lang/management/OperatingSystemMXBean.html#getSystemLoadAverage()
    //
    // TODO(user): Consider scaling by number of mutator threads,
    // e.g. using Thread#activeCount()
    return max(10L, Runtime.getRuntime().totalMemory() / (32L * 1024L * 1024L));
  }

  /**