почему надо/не надо заботиться о памяти при программировании под VM?

Все верно, все применимо, все важно. И ничего из этого не имеет отношения к физическому устройству и работе памяти.

Просто, посмотри на FF и на VSCode, которые за рабочий день набирают минимум по 4-6 GB в себя. И сможешь ответить на свой вопрос.

это и есть «оптимизация памяти по объему без доступа к железу», ровно то, что ты хотел услышать

Как можно раньше валить ссылки, чтобы gc высвобождал ресурсы эффективней, использовать ленивые вычисления, не злоупотреблять замыканиями, например.

Нет, я хотел услышать не это. Мне тут уже сказали то, что я хотел услышать: sun.misc.Unsafe. Я конечно все еще уверен что а) знать это совершенно не обязательно и б) использовать это не нужно кроме случаев ну уж совсем крайней необходимости, но я признаю что это по крайней мере оказалось действительно технически возможным.

Это все не имеет отношения к прямым оптимизациям памяти. «Не плоди лишнего» — для этого разбираться в тонкостях кэшей не обязательно. Может людям и действительно имеет смысл почитать ту статью с которой все началось, хотя бы для того чтобы понять чем же именно им, к счастью, заниматься НЕ придется.

Нужно заботится потому что абстракции текут, как всем известно.
Так они обещали что контейнеры это просто, но потом добавили -XX:-UseContainerSupport в JVM.

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

ту статью с которой все началось

Тред на форуме или какую-то стью на другом ресурсе? Если на другом, то дай линк, если есть.

ну тут скорее вопрос в том, что якобы VM освобождает (делает бесполезными) все заботы о памяти.

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

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

Почему тогда в виртуалбоксе все тормозит?

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

ну можно же как-то поменять ее поведение, косвенными средствами?

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

Наверное речь о GC, при чём тут VM.

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

На java с этим пляшут, на c# с этим пляшут, на C++ и C с этим и подавно пляшут, те кому надо.

Гугли «${SOME_VM} memory profiler». Если такой есть, тем более за бабосы, то тебе придётся продумывать кажный свой шаг и считать по байтам, как в микроконтроллерах.

Причём в современном говне всё гораздо хуже, чем в сишечке. Там тебе и линтер по рукам надаёт и профайлеров миллион и десятилетия слёзопыта программистов. А тут только ты, гугл и удача.

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

Такие дела.

Коли сиё правда - реквестирую референсные ссылки на пару таких багов в открытом коде. Или, хотя бы, патчей.

Очевидно тебе нужно не теребонькатьреквестировать, а искать «${SOME_VM} memory leak»

Кино - интересное. Благодарю.

Нужно заботиться обо всём, до чего мозги дотягиваются, чтобы эти самые мозги от собственного расп@#%яйства не протухли. Т.е. чтобы не превратиться из инженера (ежели вдруг кто себя таковым самонадеянно считает) в быдлокодера.