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

О ресурсах нужно заботиться тогда, когда их не хватает.

Преждевременная оптимизация — корень всех бед.

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

На сколько я понял morse имел в виду разработку на java, c#, js и других языках которые выполняются в виртуальной машине и не дают программисту работать с памятью

Это не имеет значения.

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

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

Ты бы сначала выяснил для себя, что такое «программирование под VM».

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

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

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

В лучае с VM типа или xen, все таки памяти напрямую отображатся в физическую, не?

Ты бы сначала выяснил для себя, что такое «программирование под VM».

вот сейчас и выясним.

То есть ты задал вопрос, не зная, о чем он. Мде.

ничего страшного. Лишние знания не помешают.

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

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

С эмуляцией, скажем x86 на ARM и наоборот могут быть нюансы

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

Например, вот так: https://github.com/LMAX-Exchange/disruptor/blob/5764f3b01faab603322c61cede957...

Угадай, зачем это нужно?

Тебе что такое виртуальная машина объяснить?

О какого рода оптимизациях речь? Если у тебя там в VM тебе не дают аллоцировать / освобождать, не факт что тебе не придется другие оптимизации применять, например исключать лишние копирования, объединять объекты, делать объекты больше / меньше и тп. А еще мож придется в кишки VM залезть (но это уже другая история, хотя бывает что там есть ручки, за которые можно дергать). А мож у тебя полно ненужных одноразовых объектов в памяти, которые просто трешат её без нужды. А может ты поджираешь пару гигов и потом копируешь их в цикле непрестанно, а всё потому, что надо пару типов данных в объекте поменять, и всё станет хорошо. Очень сильно всё зависит от ситуации...

Мне объяснить, какой смысл вкладывал ТС в слова «виртуальная машина» (VM), когда задавал вопрос.

Ну ты и Мать Тереза.
Некий деятель, страдающий наслаждающийся непогрешимостью, вместе с начальным постом снёс и целую ветку, где обсуждалось, почему это так/нетак. Вряд-ли отписавшиеся там захотят повторяться здесь. (На score нормальным людям плевать, но сам процесс получения уведомлений, что твоё сообщение снесли «за компанию», довольно неприятен.)

Если ты просто пользуешься виртуальной памятью, то на прикладном уровне без разницы. Тебе так же должен беспокоить кэш, размер объектов, alignment, структуры данных. То есть пихаешь то, что используется вместе - рядом, что раздельно - отдельно, чтобы проц за данными по всей памяти не скакал. valgrind/kcachegrind хорошо всё находит. Не вижу причин такие оптимизации не делать на ЯВУ если тормозит и надо быстрее.

Угадай, зачем это нужно?

Чтобы получить проблем вместе со сменой джава машины или даже просто с апдейтом оной до новой версии?

Это мое предположение, на самом деле я абсолютно без понятия.

В оригинале шла речь про ЯВУ и их VM (java, js).

C++ не ЯВУ уже?

С точки зрения оригинального вопроса - нет. Тут речь скорее про скриптоту, java, js и подобное, у которого VM есть. А по поводу ЯВУ C++ или нет на самом деле полно в сети срачиков и получается зависит от задач. Да и пофиг.

Не, вряд ли тут приедут проблемы кроме общих проблем java приходящих с апгрейдом (смена API).

Очень много пишут всякой низкоуровневой фигни на java, даже генераторы нативных инструкций с последующим их запуском. Это вот болезнь такая. Но к такому я отношусь с пониманием - если знаешь только один язык и сросся с ним за годы, очень сложно на другой переходить под задачу, да и желания нет. Сидел такой программер на теплом месте, писал бизнес-логику а тут к нему с оптимизациями. Казалось бы, надо быстро - напиши jniшку, всё будет зашибись, не, мы пойдём другим путем, будем писать фреймворк, который будет генерить код на asm'е строго под amd64 (x86_64), будем дергать на нем ассемблер, делать .so и грузить это .so как jni и выполнять. А на арме не работает, пишите сами...

Чтобы получить проблем вместе со сменой джава машины или даже просто с апдейтом оной до новой версии?

И каких там проблем можно получить?

Очень много пишут всякой низкоуровневой фигни на java

Ага, чтобы потом стыковать это с высокоуровневым кодом на Java. Проблема с JNI состоит в том, что с JIT-компиляцией такой код не очень хорошо дружит. Будет маленький эффективный код на сях, все преимущества которого сожрёт стыковка с JVM.

даже генераторы нативных инструкций с последующим их запуском

Это были фантазии, а затем, кажется, извращения Стиви.

Начнём с того, что «прямое обращение и взаимодейстиве с памятью» уже тыщу лет как в общем случае не возможно.

Времена DOS, Amiga, Atari, Z80 и других CP/M давно прошли. В общем случае на прямую с памятью никто давно не взаимодействует.

Linux — это тоже (хитрож*пая) витруальная машина.

Не, столкнулся с таким проектом IRL пару лет назад.

А что ты называешь прямым взаимодействием с памятью? Виртуальная память реализована аппаратно.

Ну я как бы к тому и клоню, что есть «прямое взаимодействие» с памятью?

По дороге туда у нас несколько баррикад абстракций, начиная с железа, os и других vm с runtime-мами.

Что же хотел узнать автор?

Это типа авторам дали почувствовать себя ковбоями? Именно JNI на ассемблере, причём генерируемый во время работы? Сомнительная польза.

Угадай, зачем это нужно?

ложат на cache line чтоли? )

Да. Чтобы разные ядра не воевали за одну кеш-линию при обновлениях. Говорят, отлично помогает.

sun.misc.Unsafe — приватное api. Его уже однажды грозились выпилить, и вроде как даже приступили к сему с десятой версии. В ibm j9 оно работает, судя по всему, хреново, а значит переехав, например, с openjdk на j9 запросто можно себе что-нибудь придавить. Название unsafe какбе намекает. Не надо его использовать.

Времена DOS, Amiga, Atari, Z80 и других CP/M давно прошли. В общем случае на прямую с памятью никто давно не взаимодействует.

А что такое «напрямую» в твоем понимании? Вот Rowhammer, который сбрасывает биты DRAM - это «напрямую» или нет?

Да ё-моё, третий тред про одну и ту же глупость?

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

ну тоже смотря что понимать под. haspMap vs treeMap считается?

Мда...

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

Это разве не пример плохой практики? Через какое-то время код из этой программы понадобится повторно использовать в более сложном контексте, запускать неоднократно. А то, что он «одноразовый», либо забудится, либо использовать его будет другой человек, не имеющий отношения к изначальной разработке. И получится нежданчик. Не проще ли с самого начала не писать говнокод, и явно освобождать все явно выделенные ресурсы?

Ну быстрее же стало, значит задачу выполнили. А разгребать и портировать - это уже другие люди мучаются.

Ну такие вещи редко рассматриваются как критерий при разработке. Важно что есть здесь и сейчас, а потом будет потом.

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

Тут либо «в общем случае», либо «никто». Если система конфигурируется статически на этапе разработки, все устройства В/В определены заранее и не меняются, так же как и пиковая нагрузка - зачем такой системе виртуальная память? Другое дело, что и динамического выделения ресурсов в такой системе нет.

Ой, расскажи это тем кто лоулэйтенси(хотя бы сотни микросекунд отклика) пишет на java и c#. Они оценят твой тонкий солдатский юморок.

И там и там в общем можно, хотя местами и практологическими методами. Может и в js можно, но тут я не в курсе.

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

Бессмысленный вопрос, бессмысленный ответ morse.

Звучит как бред - если память узкое место, то никакая виртуалка этого не исправит, а скорее - усугубит.

Звучит как правда - больше 90%(субъективно) разработчиков не заморачивается производительностью на таком низком уровне, т.к. память превращается в узкое место начиная с того момента когда твоя атомарная бизнес операция должна занимать меньше половины миллисекунды(условно, эта величина ежедневно уменьшается), согласно нефункциональным требованиям. А большинство разработки - web и интернет, там другие времена откликов, на порядки и десятки порядков выше.

ну тоже смотря что понимать под. haspMap vs treeMap считается?

Не, это структуры данных, они имеют мало отношения к физической памяти.

при освобождении памяти можно выйти за границы массива, поэтому нужно использовать безопасные языки и не думать о таких мелочах: java, rust, go и тд. Си - позапрошлый век, или когда там динозавры съели все листья и вымерли...

Что значит заботиться о памяти?

Не разбазаривать - да, нужно.

Не писать тупые алгоритмы - да, нужно.

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

Очень точно считать потребление памяти - тоже, только если нужно. Обычно нет и более того, невозможно нормально посчитать

https://github.com/search?l=Rust&q="unwrap()"&type=Code

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

Вот знаешь, многие программы сейчас работают так, что задумываешься о том, что хорошо бы было разработчиков пересадить на какой-нибудь P4 с 512 МБ памяти. Ну, по праздникам за примерное поведение выдавать ещё планку на 256.

отдавать предпочтения примитивным типам, вместо их объектных оберток, минимизировать число используемых объектов, не плодить их копии, использовать структуры на основе массивов например ArrayList вместо LinkedList.