[makc 192]

14 минут назад, dxp сказал:

Вам известны случаи падения программ, например, на x86 из-за того, что фрагментация "побила" всю память?

На сколько я помню Firefox страдал от этой проблемы (https://support.mozilla.org/en-US/questions/1115812), но он не одинок: https://www.ibm.com/support/pages/resolving-memory-problems-using-low-fragmentation-heap-lfh

[dxp 34]

Не понятно, почему именно ломалось. Если 64-разрядная модель памяти, то забить её всю, это надо очень постараться. По второй ссылке лечение с помощью  какого-то патча. Т.е. пофиксили программно. Думается, на системе без MMU  никакими патчами фрагментацию купировать не получится.

[jcxz 184]

31 минуту назад, dxp сказал:

Думается, на системе без MMU  никакими патчами фрагментацию купировать не получится.

Вообще-то по большому счёту - можно. Алгоритмически. Но сложно.

Алгоритмически - реализовав свою сборку мусора. Например:

Периодически запуская циклы "сборки мусора" (выполняет дефрагментацию кучи). Запускаться циклы "сборки мусора" должны из критической секции. Все операции с выделенными из кучи данными - тоже только внутри этой критической секции (только пользователи кучи владеют секцией совместно, но захватывают - каждый самостоятельно). Указатели на все выделенные блоки сохраняются в некоем массиве (который корректируется сборщиком мусора). Пользователи должны периодически отпускать критическую секцию и заново захватывать её, при каждом новом запуске считывая указатель на свой выделенный блок из массива и пересчитывая заново все производные от него указатели (если нужны). Пользователи между освобождением и захватом критической секции не должны хранить никакие производные указатели от выделенного блока, только заново их генерировать при каждом новом захвате критической секции.

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

В Яве это сделали на уровне системы - убрав указатели и позволив работать с массивами только через индексы. И добавив системный "сборщик мусора". Но это понижает эффективность кода.

[Axel 1]

Вопрос решился просто: списал переопределение менеджера у Cereal (либа сериализации).
Про область применения: IoT (ближе к кофеварке, чем к марсоходу). По поводу джейсонов: они (в моем случае) разные бывают - от пары десятков байт до 2.5к (редко). Выделять память статически на максимум плохо, поскольку памяти дефицит. Поэтому, и по совокупности других обстоятельств, куча предпочтительнее. Кроме того, в определенных ситуациях (напр. если надо открыть еще один сокет) от длинных джейсонов я могу на время отписаться.

[jcxz 184]

25 минут назад, Axel сказал:

Выделять память статически на максимум плохо, поскольку памяти дефицит. Поэтому, и по совокупности других обстоятельств, куча предпочтительнее.

Так если "памяти дефицит", то тем более куча - зло. Так как потребует больше памяти для такого же размера JSON.

Ещё раз:

В 23.05.2023 в 13:14, jcxz сказал:

Макс.размер JSON-а скажем == 100 байт. Соответственно резервировать имеет смысл 100 байт. Но только при статическом выделении это и будет 100 байт потрачено, а при динамическом == 100 байт + заголовок блока + потери на фрагментацию.

[Axel 1]

Ситуации у меня в общем альтернативные (как я и писал). А "кооперативно" использовать статическую память для объектов разной природы - ИМХО, слишком высокое искусство (особенно для последующей поддержки). Так что пока - куча.

[mantech 34]

8 часов назад, Axel сказал:

Выделять память статически на максимум плохо, поскольку памяти дефицит.

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

[Axel 1]

Согласен. Я тоже пользую union и placement new везде, где возможно. Но в проекте, по поводу которого топик, присутствует SDK, построенный на freeRTOS, включающий lwip, А там свои дела с кучей. Ну и rapidjson, очень удобная, но внутри сильно динамическая.

[Axel 1]

Если кому-нибудь еще интересно: в конце концов все обошлось статическим буфером (нашел здесь). Пока все нравится.