compact1, compact2, compact3

java.lang.invoke

Класс MutableCallSite

java.lang. Объект

java.lang.invoke. CallSite

java.lang.invoke. MutableCallSite

public class MutableCallSite
extends CallSite

A MutableCallSite a CallSite чья целевая переменная ведет себя как обычное поле. invokedynamic инструкция, соединенная с a MutableCallSite делегаты все звонки в текущую цель сайта. Динамический invoker изменчивого сайта вызова также делегирует каждый звонок в текущую цель сайта.

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

MutableCallSite name = new MutableCallSite(MethodType.methodType(String.class));
MethodHandle MH_name = name.dynamicInvoker();
MethodType MT_str1 = MethodType.methodType(String.class);
MethodHandle MH_upcase = MethodHandles.lookup()
    .findVirtual(String.class, "toUpperCase", MT_str1);
MethodHandle worker1 = MethodHandles.filterReturnValue(MH_name, MH_upcase);
name.setTarget(MethodHandles.constant(String.class, "Rocky"));
assertEquals("ROCKY", (String) worker1.invokeExact());
name.setTarget(MethodHandles.constant(String.class, "Fred"));
assertEquals("FRED", (String) worker1.invokeExact());
// (mutation can be continued indefinitely)
 

Тот же самый сайт вызова может быть использован в нескольких местах сразу.

MethodType MT_str2 = MethodType.methodType(String.class, String.class);
MethodHandle MH_cat = lookup().findVirtual(String.class,
  "concat", methodType(String.class, String.class));
MethodHandle MH_dear = MethodHandles.insertArguments(MH_cat, 1, ", dear?");
MethodHandle worker2 = MethodHandles.filterReturnValue(MH_name, MH_dear);
assertEquals("Fred, dear?", (String) worker2.invokeExact());
name.setTarget(MethodHandles.constant(String.class, "Wilma"));
assertEquals("WILMA", (String) worker1.invokeExact());
assertEquals("Wilma, dear?", (String) worker2.invokeExact());
 

Несинхронизация целевых значений: запись к изменчивой цели сайта вызова не вынуждает другие потоки узнать обновленное значение. Потоки, которые не выполняют подходящие действия синхронизации относительно обновленного сайта вызова, могут кэшировать старое целевое значение и задержать их использование нового целевого значения неопределенно. (Это - нормальное последствие Модели памяти Java в применении к объектным полям.)

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

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

Сводка конструктора

Конструкторы

Конструктор и Описание
MutableCallSite(MethodHandle target) Создает объект сайта вызова с начальным целевым дескриптором метода.
MutableCallSite(MethodType type) Создает пустой объект сайта вызова с данным типом метода.

Сводка метода

Модификатор и Тип	Метод и Описание
MethodHandle	dynamicInvoker() Производит дескриптор метода, эквивалентный invokedynamic инструкции, которая была соединена с этим сайтом вызова.
MethodHandle	getTarget() Возвращает целевой метод сайта вызова, который ведет себя как нормальное поле MutableCallSite.
void	setTarget(MethodHandle newTarget) Обновляет целевой метод этого сайта вызова, как нормальная переменная.
static void	syncAll(MutableCallSite[] sites) Выполняет работу синхронизации на каждом сайте вызова в данном массиве, вынуждая все другие потоки выбросить любые кэшируемые значения, ранее загруженные из цели любого из сайтов вызова.

Методы, наследованные от class java.lang.invoke. CallSite

ввести

Методы, наследованные от class java.lang. Объект

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Деталь конструктора

MutableCallSite

public MutableCallSite(MethodType type)

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

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

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

Параметры:

type - тип метода, который будет иметь этот сайт вызова

Броски:

NullPointerException - если предложенный тип является нулем

MutableCallSite

public MutableCallSite(MethodHandle target)

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

Параметры:

target - дескриптор метода, который будет начальной целью сайта вызова

Броски:

NullPointerException - если предложенная цель является нулем

Деталь метода

getTarget

public final MethodHandle getTarget()

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

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

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

Определенный:

getTarget в class CallSite

Возвраты:

состояние редактирования этого сайта вызова, дескриптор метода, который может измениться в течение долгого времени

См. Также:

setTarget(java.lang.invoke.MethodHandle)

setTarget

public void setTarget(MethodHandle newTarget)

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

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

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

Определенный:

setTarget в class CallSite

Параметры:

newTarget - новая цель

Броски:

NullPointerException - если предложенная новая цель является нулем

WrongMethodTypeException - если у предложенной новой цели есть тип метода, который отличается от предыдущей цели

См. Также:

getTarget()

dynamicInvoker

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)
 

Определенный:

dynamicInvoker в class CallSite

Возвраты:

дескриптор метода, который всегда вызывает эту текущую цель сайта вызова

syncAll

public static void syncAll(MutableCallSite[] sites)

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

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

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

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

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

Если sites содержит нулевой элемент, a NullPointerException будет повышен. В этом случае некоторые ненулевые элементы в массиве могут быть обработаны прежде, чем метод возвращается неправильно. То, какие элементы они (если любой) является зависящим от реализации.

Детали Модели памяти Java

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

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

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

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

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

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

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

Параметры:

sites - массив сайтов вызова, которые будут синхронизироваться

Броски:

NullPointerException - если sites ссылка массива является нулем, или массив содержит нуль