Саша, ты лучше скажи мне другое. Левенталь говорил, что похожим образом легко сделать eviction для L1 instruction. Но наскоком у меня такой тест не вышел. Сделаешь? ;)
Как все запущено. :(
Escape Analysis НЕ размещает объекты на «стеке вместо кучи». Escape Analysis — это анализ, а не оптимизация. Он вообще ничего оптимизирует, а только проводит анализ кода и предоставляет полученную информацию другим частям HotSpot'а которые и делают оптимизацию. Это первое.
Второе — размещения объектов на стеке нет. Вообще, такая оптимизация возможна и даже есть альтернативные JVM в которых это реализовано. Вместо этого HotSpot содержит другую оптимизацию, которая называется Scalar replacement. То есть если объект локален (не убегает), то его можно заменить на россыпь локалов (которые, при сотворении кода девелопером, были полями этого объекта). То есть вместо объекта (композитной сущности ) — получаем кучку скаляров. Это и есть Scalar Replacement.
Ключика включать Scalar Replacement нет. Он всегда включен, просто если выключить Escape анализ — то для него не будет информации и он ничего не сделает.
non globally escaping object — это объект который убегает из данного метода, но не убегает из цепочки вызовов (и соответственно не убегает из треда). Для такого объекта можно спокойно удалить синхронизацию (не убегает из треда). При этом убегание из метода по цепочке вызовов может быть разное: убегает только вниз по цепочке, убегает только вверх или туда и сюда. Для случая убегания только вниз можно разместить объект на стеке (для остальных так просто нельзя). Так вот, там сказано, что C2 этим не заморачивается. ;)
Совершенно некорректные вопросы.
Вопрос: «Может ли null использоваться в качестве ключа в Map?»
Правильный ответ: Так как Map это интерфейс — то зависит от реализации.
Подсказка: курим реализации (а также спецификации) HashMap, ConcurrentHashMap & Hashtable (который тоже Map).
Вопрос: «Может ли Set содержать null?»
Ответ: ну вы поняли. ;)
Надо БЫЛО.
«Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!» (с)
Обновлять нужно знания — не стоить тиражировать замшелые мифы. ;)
Если у вас
1. Результат инкремента ни где не используется
2. У вас не древний древний компилятор (если С++) (или JVM моложе как минимум начала 1999 года)
то => код сгенерированный обоих случаях будет один и тот же.
Я могу понять ++ vs ++ в C++ где иногда в итераторах ТАКОЕ может быть написано ;) Вот там преинкремент итератора действительно имеет смысл(просто на всякий случай, чтобы не продираться через горы инклюдов и ифдефоф).
ВластиОракл скрывает!!!Escape Analysis НЕ размещает объекты на «стеке вместо кучи». Escape Analysis — это анализ, а не оптимизация. Он вообще ничего оптимизирует, а только проводит анализ кода и предоставляет полученную информацию другим частям HotSpot'а которые и делают оптимизацию. Это первое.
Второе — размещения объектов на стеке нет. Вообще, такая оптимизация возможна и даже есть альтернативные JVM в которых это реализовано. Вместо этого HotSpot содержит другую оптимизацию, которая называется Scalar replacement. То есть если объект локален (не убегает), то его можно заменить на россыпь локалов (которые, при сотворении кода девелопером, были полями этого объекта). То есть вместо объекта (композитной сущности ) — получаем кучку скаляров. Это и есть Scalar Replacement.
Ключика включать Scalar Replacement нет. Он всегда включен, просто если выключить Escape анализ — то для него не будет информации и он ничего не сделает.
Ну не должен же я все подряд писать. Некоторые очевидные вещи можно опускать. ;)
Вопрос: «Может ли null использоваться в качестве ключа в Map?»
Правильный ответ: Так как Map это интерфейс — то зависит от реализации.
Подсказка: курим реализации (а также спецификации) HashMap, ConcurrentHashMap & Hashtable (который тоже Map).
Вопрос: «Может ли Set содержать null?»
Ответ: ну вы поняли. ;)
«Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!» (с)
Обновлять нужно знания — не стоить тиражировать замшелые мифы. ;)
а например dup со святым духом работает? ;)
1. Результат инкремента ни где не используется
2. У вас не древний древний компилятор (если С++) (или JVM моложе как минимум начала 1999 года)
то => код сгенерированный обоих случаях будет один и тот же.
Я могу понять ++ vs ++ в C++ где иногда в итераторах ТАКОЕ может быть написано ;) Вот там преинкремент итератора действительно имеет смысл(просто на всякий случай, чтобы не продираться через горы инклюдов и ифдефоф).