Класс MutableCallSite

public MutableCallSite(MethodType type)

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

Тип сайта вызова навсегда устанавливается равным заданному типу.

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

public MutableCallSite(MethodHandle target)

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

public final MethodHandle getTarget()

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

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

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

public void setTarget(MethodHandle newTarget)

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

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

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

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. В этом случае некоторые ненулевые элементы массива могут быть обработаны до того, как метод завершится аварийно. Какие именно элементы (если таковые имеются) будут обработаны, зависит от реализации.

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

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

Для каждого отдельного сайта вызова S проявляются следующие эффекты:

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

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

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

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

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