Класс MutableCallSite

public MutableCallSite(MethodType type)

Создаёт пустой объект вызова с заданным типом метода. Начальное целевое значение устанавливается в метод-обработчик заданного типа, вызов которого приведёт к исключению IllegalStateException.

Тип вызова устанавливается окончательно, согласно заданному типу.

Перед тем, как этот CallSite объект возвращается методом-обработчиком или вызывается каким-либо другим способом, ему обычно присваивается более полезный целевой метод, с помощью вызова setTarget.

public MutableCallSite(MethodHandle target)

Создаёт объект вызова с начальным методом-обработчиком. Тип вызова окончательно устанавливается на тип начального целевого метода-обработчика.

public final MethodHandle getTarget()

Возвращает целевой метод вызова, который ведёт себя как обычное поле объекта MutableCallSite.

Взаимодействие getTarget с памятью аналогично чтению из обычной переменной, например, элемента массива или не-volatile, не-final поля.

В частности, текущая нить может выбрать повторное использование результата предыдущего чтения целевого значения из памяти и может не увидеть недавнее обновление целевого значения другой нитью.

public void setTarget(MethodHandle newTarget)

Обновляет целевой метод данного вызова, как обычную переменную. Тип нового целевого значения должен совпадать с типом предыдущего целевого значения.

Взаимодействие с памятью аналогично записи в обычную переменную, например, элемент массива или не-volatile, не-final поле.

В частности, не связанные нити могут не увидеть обновлённое целевое значение до тех пор, пока они не выполнят чтение из памяти. Более сильные гарантии могут быть созданы, разместив соответствующие операции в методе-обработчике и/или целевых методах, используемых в данном месте вызова.

public final MethodHandle dynamicInvoker()

Создаёт метод-обработчик, эквивалентный инструкции invokedynamic, которая была связана с этим местом вызова.

Этот метод эквивалентен следующему коду:

 MethodHandle getTarget, invoker, result;
 getTarget = MethodHandles.publicLookup().bind(this, "getTarget", MethodType.methodType(MethodHandle.class));
 invoker = MethodHandles.exactInvoker(this.type());
 result = MethodHandles.foldArguments(invoker, getTarget)
 

public static void syncAll(MutableCallSite[] sites)

Выполняет операцию синхронизации для каждого места вызова в заданном массиве, заставляя все другие нити отбросить любые кэшированные значения, ранее загруженные из целевого значения любого из мест вызова.

Эта операция не отменяет вызовы, которые уже начались с устаревшим значением целевого объекта. (Java поддерживает только движение вперёд во времени.)

Общий эффект заключается в том, что все последующие читатели для каждого места вызова будут принимать наиболее недавно сохранённое значение. ("Наиболее недавно" определяется относительно самого syncAll.) Напротив, вызов syncAll может заблокироваться до тех пор, пока все читатели (каким-либо способом) не откажутся от всех предыдущих версий целевого значения каждого места вызова.

Чтобы избежать гонок, вызовы setTarget и syncAll, как правило, должны выполняться под какой-либо формой взаимной исключительности. Обратите внимание, что нити-читатели могут наблюдать обновлённое целевое значение уже в момент вызова setTarget, который устанавливает значение (и до подтверждения syncAll этого значения). С другой стороны, нити-читатели могут наблюдать предыдущие версии целевого значения до тех пор, пока не вернётся вызов syncAll (и после попытки setTarget передать обновлённую версию).

Эта операция, вероятно, будет дорогостоящей и должна использоваться экономно. Если возможно, она должна буферизироваться для пакетной обработки набора мест вызова.

Если в sites есть элемент null, будет выброшено исключение NullPointerException. В этом случае некоторые не-null элементы массива могут быть обработаны до того, как метод вернёт исключение. Какие именно элементы это (если таковые имеются) зависит от реализации.

Подробности модели памяти Java

С точки зрения модели памяти Java, эта операция выполняет действие синхронизации, которое по своему эффекту сравнимо с записью переменной volatile текущей нитью и последующим чтением этой переменной volatile всеми остальными нитями, которые могут получить доступ к одному из затронутых мест вызова.

Следующие эффекты очевидны для каждого отдельного места вызова S:

• Создаётся новая переменная volatile V, и она записывается текущей нитью. Как определено JMM, эта запись является глобальным событием синхронизации.
• Как обычно при упорядочении событий записи в рамках одной нити, каждое действие, уже выполненное текущей нитью, считается выполненным до записи volatile в V. (В некоторых реализациях это означает, что текущая нить выполняет глобальную операцию освобождения.)
• В частности, запись в текущее целевое значение S считается выполненной до записи volatile в V.
• Запись volatile в V размещается (по способу, зависящему от реализации) в глобальном порядке синхронизации.
• Рассмотрим произвольную нить T (отличную от текущей нити). Если T выполнит действие синхронизации A после записи volatile в V (в глобальном порядке синхронизации), она, следовательно, должна увидеть либо текущее целевое значение S, либо более позднюю запись в это целевое значение, если она выполнит чтение целевого значения S. (Это ограничение называется "последовательной согласованностью синхронизации").
• JMM специально разрешает оптимизаторам компилятора опускать чтения или записи переменных, которые известны как бесполезные. Такие пропущенные чтения и записи не оказывают влияния на отношение "happens-before". Несмотря на это, переменная volatile V не будет опущена, даже если её записанное значение неопределённо, и её считанное значение не используется.

Из-за последнего пункта реализация ведёт себя так, как будто нить T выполнила чтение volatile V непосредственно после своего действия A. В локальном порядке действий в T это чтение происходит до любого последующего чтения целевого значения S. Это как если бы реализация произвольно выбрала чтение целевого значения S нитью T и принудила чтение V предшествовать ему, тем самым обеспечив передачу нового целевого значения.

До тех пор, пока соблюдаются ограничения модели памяти Java, реализации могут откладывать завершение операции syncAll, в то время как другие нити (T выше) продолжают использовать предыдущие значения целевого значения S. Однако реализации (как всегда) должны избегать блокировки, и в конечном итоге потребовать, чтобы все нити учли обновлённое целевое значение.

Обсуждение: По причинам производительности, syncAll не является виртуальным методом на одном месте вызова, а скорее применяется к набору мест вызова. Некоторые реализации могут иметь большие фиксированные накладные расходы при обработке одной или нескольких операций синхронизации, но небольшие добавочные расходы для каждого дополнительного места вызова. В любом случае, эта операция, вероятно, будет дорогостоящей, поскольку другим нитям может потребоваться прервать их работу, чтобы заставить их заметить обновлённое значение целевого объекта. Тем не менее, можно заметить, что один вызов для синхронизации нескольких мест имеет такой же формальный эффект, как и много вызовов, каждый для только одного места.

Примечание по реализации: Простые реализации MutableCallSite могут использовать переменную volatile для целевого значения места вызова. В такой реализации метод syncAll может быть пустым, и тем не менее он будет соответствовать поведению JMM, описанному выше.