Так как сейчас правильно выделять память в приложении?

С твоего незнакомства с матчастью, увы.

Эта тема по эпичности скоро будет похожа на легендарную «взлетит или не взлетит».

Две темы это уже обсуждали. И уже множество лет в подобных темах.

Самый правильный способ это выделить буфер константного размера на старте программы

Из того, что выделил какой-то «буфер», которого не существует - из этого ничего не следует. Никакого буфера нет. Ты выделил пустоту константного размера, в которой 0памяти. И память там будет появляться по мере использования.

А это значит, что в любой момент ты можешь словить oom.

Неважно что такое жава. Я уже объяснил в чём заключается подмена понятий. Когда мы сравниваем какую-то жаву с процессами, то мы не можем сравнивать жаву с процессами. Мы можем сравнивать только жвм, а жвм такая же программа, которая работает с той же системой и по таким же принципам, как и всё остальное.

По поводу «Падает, но не падает» - тебе уже привели пример с виртуалкой. Оно падает в рамках «процесса» жвм, а не в рамках процесса ОС. При этом точно так же оно может падает и в рамках процесса, но это можно обрабатывать, а не падать. При этом самой жвм ничего падать не мешает.

Поэтому «не падает» жабки распространяется только на внутреннюю логику жвм, а не на самом процесс, который крутиться. Аналогичное работает и для всего остального.

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

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

Спасибо, наконец-то я все понял.

С чего бы это? Это самый рабочий способ.

Этот способ ровно никак не отличается от выделения большого буфера после долгой работы программы.

С чего бы это? Это самый рабочий способ.

Так из-за таких удаков и сделали оверкоммит. Все так или иначе берут впрок большие куски и потом с ними ничего не делают. Например, ff держит раза в 4-6 больше анонимной памяти чем использует. Проблему подогревают многопоточные приложения.

Так из-за таких удаков и сделали оверкоммит.

Трепло, иди проспись.

Иди и читай до просветления: https://code.woboq.org/linux/linux/mm/util.c.html#__vm_enough_memory

Иди и читай до просветления...

Ну и что тебе из этого кода не понятно, овощ?

По этой теме сразу возникает вопрос. Допустим, в программе создаются и удаляются энное количество объектов. В процессе выясняется, что возникла высокая фрагментация. И как обычно с этим борятся: на уровне архитектуры аппы или всё применяются какие-то негласные правила?

По этой теме сразу возникает вопрос ... возникла высокая фрагментация. И как обычно с этим борятся ...?

А как ты борешься с фрагментацией в обычной куче? Статический буфер тут новых проблем не прибавляет, даже наоборт - избавляет от них т.к. обычно в подобном варианте буфер партиционируется сразу под все виды объектов (в пулы объектов или чанков определённого размера) и дальнейшего перераспределения памяти между ними не происходит.

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

Ну и что тебе из этого кода не понятно, овощ?

Раскудахтался? Ну вот, ты там же кукарекал о том, что «сделали оверкоммит» - найди мне так «сделанный оверкоммит». Я знаю - ты сможешь.

Реально на второй круг пошли? Дали же уже советы дельные

Эту проблему не надо решать. Надо просто заранее создать все возможные объекты в нужном количестве, а в процессе работы переводить их из спящего состояния в активное и наоборот.

Или выделять их в memory pool по мере надобности

В процессе выясняется, что возникла высокая фрагментация.

С этим есть так же много нюансов. Почему вообще берётся фрагментации в хипе? Откуда? Я тебе отвечу - от строк. Ничто другое в 95% случаев хип не фрагментирует.

И как обычно с этим борятся: на уровне архитектуры аппы или всё применяются какие-то негласные правила?

С этим никто не борется в подавляющем большинстве случаев. Вот мы много раз слышали от балаболов то, что строки типа «бесплатные» и никаких проблем нет.

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

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

На уровне же памяти(реализации) эта задача нерешаема. А когда она решена «свыше» - её не надо решать на уровне ниже. На уровне ниже уже решенную задачу можно запороть, но это такое.

Никак. Есть ulimit чтобы отдельный процесс не выжирал всю память, и есть mlock чтобы память не выгружалась в swap (требующих соответствующих привилегий). Больше ничего сделать нельзя. Никакие заранее-выделения-памяти не помогут, поскольку они будут вытеснены в swap, а потом приложение будет убито при попытке к ним обратиться, когда памяти куда их можно было бы загрузить не будет. Это плата за универсальность и производительность системы, в том числе за экономию памяти.

И в нужный момент скажет русским языком, «в системе не хватает памяти, закройте ненужные приложения».

мегеге, точно так же молча пристреливается, проверено электрониками (с)