makc 232 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 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 67 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба Не понятно, почему именно ломалось. Если 64-разрядная модель памяти, то забить её всю, это надо очень постараться. По второй ссылке лечение с помощью какого-то патча. Т.е. пофиксили программно. Думается, на системе без MMU никакими патчами фрагментацию купировать не получится. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 31 минуту назад, dxp сказал: Думается, на системе без MMU никакими патчами фрагментацию купировать не получится. Вообще-то по большому счёту - можно. Алгоритмически. Но сложно. Алгоритмически - реализовав свою сборку мусора. Например: Периодически запуская циклы "сборки мусора" (выполняет дефрагментацию кучи). Запускаться циклы "сборки мусора" должны из критической секции. Все операции с выделенными из кучи данными - тоже только внутри этой критической секции (только пользователи кучи владеют секцией совместно, но захватывают - каждый самостоятельно). Указатели на все выделенные блоки сохраняются в некоем массиве (который корректируется сборщиком мусора). Пользователи должны периодически отпускать критическую секцию и заново захватывать её, при каждом новом запуске считывая указатель на свой выделенный блок из массива и пересчитывая заново все производные от него указатели (если нужны). Пользователи между освобождением и захватом критической секции не должны хранить никакие производные указатели от выделенного блока, только заново их генерировать при каждом новом захвате критической секции. Выполняя все эти условия, работая с указателями аккуратно, можно свести к минимуму вред от дефрагментации кучи. Но кто же из куче-пользователей станет так дисциплинированно себя и вести и писать код так аккуратно?? Вопрос ясное дело - риторический. В Яве это сделали на уровне системы - убрав указатели и позволив работать с массивами только через индексы. И добавив системный "сборщик мусора". Но это понижает эффективность кода. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба Вопрос решился просто: списал переопределение менеджера у Cereal (либа сериализации). Про область применения: IoT (ближе к кофеварке, чем к марсоходу). По поводу джейсонов: они (в моем случае) разные бывают - от пары десятков байт до 2.5к (редко). Выделять память статически на максимум плохо, поскольку памяти дефицит. Поэтому, и по совокупности других обстоятельств, куча предпочтительнее. Кроме того, в определенных ситуациях (напр. если надо открыть еще один сокет) от длинных джейсонов я могу на время отписаться. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 25 минут назад, Axel сказал: Выделять память статически на максимум плохо, поскольку памяти дефицит. Поэтому, и по совокупности других обстоятельств, куча предпочтительнее. Так если "памяти дефицит", то тем более куча - зло. Так как потребует больше памяти для такого же размера JSON. Ещё раз: В 23.05.2023 в 13:14, jcxz сказал: Макс.размер JSON-а скажем == 100 байт. Соответственно резервировать имеет смысл 100 байт. Но только при статическом выделении это и будет 100 байт потрачено, а при динамическом == 100 байт + заголовок блока + потери на фрагментацию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба Ситуации у меня в общем альтернативные (как я и писал). А "кооперативно" использовать статическую память для объектов разной природы - ИМХО, слишком высокое искусство (особенно для последующей поддержки). Так что пока - куча. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 53 24 мая, 2023 Опубликовано 24 мая, 2023 · Жалоба 8 часов назад, Axel сказал: Выделять память статически на максимум плохо, поскольку памяти дефицит. Ну например у меня в программе немало статических массивов, но многие одновременно не используются, поэтому прекрасно подходят для использования различными модулями непосредственно в тех же типах или через union в других. Получается экономно и практично. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 25 мая, 2023 Опубликовано 25 мая, 2023 · Жалоба Согласен. Я тоже пользую union и placement new везде, где возможно. Но в проекте, по поводу которого топик, присутствует SDK, построенный на freeRTOS, включающий lwip, А там свои дела с кучей. Ну и rapidjson, очень удобная, но внутри сильно динамическая. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 26 июня, 2023 Опубликовано 26 июня, 2023 · Жалоба Если кому-нибудь еще интересно: в конце концов все обошлось статическим буфером (нашел здесь). Пока все нравится. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
