Ну, есть коллекции, доступ к элементам которых по индексу получить нельзя. И если в Ваш метод может прийти одна из таких коллекций на ряду с индексными, то как написать универсальный метод без итератора?
Так как речь о java, то Ваши «структуры» воспринимаются исключительно как объекты. А объекты могут быть созданы на стеке (не посредством языка, а виртуальной машиной).
Да, включен по умолчанию. Но его можно выключить. Еще — чем больше стек вызовов, переменных в каждом из методов тем меньше памяти остается. Что сводит вероятность создания на стеке к весьма малому числу.
>>не могу понять что тут хотят сказать в последнем предложении.
Наверное опечатка, думаю имелось в виду, что объекты, которые выходят за область видимости метода не создаются на стеке.
Да, Вы права. Но это случается не часто. Полагаться на это не стоит.
Во-первых, escape analysis не всегда возможен в виду ограниченности стека.
Во-вторых, escape analysis может быть банально отключен.
На самом деле это ожидаемое поведение. Для коллекций свой for, для массивов свой. Ведь возможна ситуация когда на вызов метода iterator() возможна некая логика…
Вот пример из жизни — habrahabr.ru/post/147552/ о котором я недавно писал. В этом случае коротко живущие объекты не только влияли на производительность, но и приводили к постоянному срабатыванию сборщика что просто вешало машину. Я уже не говорю про десятки таких мест в высоконагруженных системах.
По второму — спасибо за замечание, подправил. Я не правильно понял термин Scalar replacement.
Так как речь о java, то Ваши «структуры» воспринимаются исключительно как объекты. А объекты могут быть созданы на стеке (не посредством языка, а виртуальной машиной).
>>не могу понять что тут хотят сказать в последнем предложении.
Наверное опечатка, думаю имелось в виду, что объекты, которые выходят за область видимости метода не создаются на стеке.
Не совсем правдивое.
Во-первых, escape analysis не всегда возможен в виду ограниченности стека.
Во-вторых, escape analysis может быть банально отключен.