В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

pro.jvm

4978 membersпожаловаться на группу
2020 June 13

VS

Vladimir Sitnikov in pro.jvm
Tagir
Ну если все объекты - это мусор, то копирующий гц тоже отработает минорную сборку очень быстро
Разумеется, мусор. Но в случае стека вообще gc делать не нужно, safepoint'ы не нужны и т.п.

Но, конечно, объекты вообще пропасть могут из-за скаляризации, и тогда и стек не особо нужен
источник
19:16пожаловаться#1

N

Nick in pro.jvm
Tagir
Я делал это. Весьма приятно
может тогда направишь прямо в код коммунки где это все варится, чтоб глазами глянуть?
источник
19:16пожаловаться#2

T

Tagir in pro.jvm
Ну то есть может быть можно было бы получить некоторое преимущество, но оно кажется весьма маргинальным. Между тем стек - слишком дорогой ресурс, чтобы раскидываться. В джаве глубина в двести вызовов запросто может быть. Смысл ещё объекты на стеке держать? Soe словите за милую душу.
источник
19:18пожаловаться#3

T

Tagir in pro.jvm
Потом вопрос, могут ли в этих объектах быть ссылки вовне. Если да, то эти объекты должны добавляться в рутсет при сборке. Помимо обычной карты регистров. Если нет, польза минимальна
источник
19:19пожаловаться#4

T

Tagir in pro.jvm
Неясно даже как на них ссылаться. Ссылки в кучу могут компактизироваться. А тут как? Все стеки всех тредов тоже в пределах адресного пространства кучи держать?
источник
19:20пожаловаться#5

T

Tagir in pro.jvm
Я думаю, ряд существующих оптимизаций вм просто отвалится, если разрешить такое. Может интегрально только медленнее стать
источник
19:20пожаловаться#6

AB

Alessio Bratenkov in pro.jvm
а напомните - какая максимальная глубина рекурсии в Джаве
источник
19:21пожаловаться#7

T

Tagir in pro.jvm
Nick
может тогда направишь прямо в код коммунки где это все варится, чтоб глазами глянуть?
Ищи StreamApiMigrationInspection и StreamToLoopInspection и оттуда или
источник
19:21пожаловаться#8

T

Tagir in pro.jvm
Alessio Bratenkov
а напомните - какая максимальная глубина рекурсии в Джаве
Он во фреймах не выражается. Зависит от размера стека в килобайтах, задаётся через -Xss
источник
19:22пожаловаться#9

N

Nick in pro.jvm
Tagir
Ищи StreamApiMigrationInspection и StreamToLoopInspection и оттуда или
Спасибо
источник
19:22пожаловаться#10

VS

Vladimir Sitnikov in pro.jvm
Tagir
Ну то есть может быть можно было бы получить некоторое преимущество, но оно кажется весьма маргинальным. Между тем стек - слишком дорогой ресурс, чтобы раскидываться. В джаве глубина в двести вызовов запросто может быть. Смысл ещё объекты на стеке держать? Soe словите за милую душу.
Это другой вопрос. Вот в CLR, вроде как есть stackalloc int[length]

И это может быть полезно (там-то оно крайне полезно, ведь gc тормозит)

Но в Java очень врядли сделают stackalloc или подобный механизм ручного указания 'как компилировать'
источник
19:22пожаловаться#11

T

Tagir in pro.jvm
Но каждый фрейм может быть разного размера. Причём интерпретируемые фреймы сильно больше занимают
источник
19:22пожаловаться#12

AB

Alessio Bratenkov in pro.jvm
спасиюо!
источник
19:23пожаловаться#13

T

Tagir in pro.jvm
Vladimir Sitnikov
Это другой вопрос. Вот в CLR, вроде как есть stackalloc int[length]

И это может быть полезно (там-то оно крайне полезно, ведь gc тормозит)

Но в Java очень врядли сделают stackalloc или подобный механизм ручного указания 'как компилировать'
Для этого апи нативной памяти придумали. Опять же просто нативная памяти ничем не хуже стека
источник
19:23пожаловаться#14

T

Tagir in pro.jvm
Отмотай себе байтбуфер и радуйся
источник
19:23пожаловаться#15

OO

Oleksandr Olgashko in pro.jvm
Tagir
Ну то есть может быть можно было бы получить некоторое преимущество, но оно кажется весьма маргинальным. Между тем стек - слишком дорогой ресурс, чтобы раскидываться. В джаве глубина в двести вызовов запросто может быть. Смысл ещё объекты на стеке держать? Soe словите за милую душу.
а когда можно вляпаться в SOE, кроме рекурсивных алгоритмов? (а для тех обычно есть хвостовая оптимизация)
источник
19:25пожаловаться#16

VS

Vladimir Sitnikov in pro.jvm
Tagir
Для этого апи нативной памяти придумали. Опять же просто нативная памяти ничем не хуже стека
Customer[] так не сделаешь на байтах. Сериализовать придётся
источник
19:25пожаловаться#17

T

Tagir in pro.jvm
Vladimir Sitnikov
Customer[] так не сделаешь на байтах. Сериализовать придётся
А в шарпе сделаешь на стеке?
источник
19:26пожаловаться#18

T

Tagir in pro.jvm
Oleksandr Olgashko
а когда можно вляпаться в SOE, кроме рекурсивных алгоритмов? (а для тех обычно есть хвостовая оптимизация)
"обычно", ха
источник
19:27пожаловаться#19

T

Tagir in pro.jvm
В джаве нет tailrec
источник
19:27пожаловаться#20