makc 385 May 24, 2023 Posted May 24, 2023 · Report post 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 Quote Share this post Link to post Share on other sites More sharing options...
dxp 213 May 24, 2023 Posted May 24, 2023 · Report post Не понятно, почему именно ломалось. Если 64-разрядная модель памяти, то забить её всю, это надо очень постараться. По второй ссылке лечение с помощью какого-то патча. Т.е. пофиксили программно. Думается, на системе без MMU никакими патчами фрагментацию купировать не получится. Quote Share this post Link to post Share on other sites More sharing options...
jcxz 361 May 24, 2023 Posted May 24, 2023 · Report post 31 минуту назад, dxp сказал: Думается, на системе без MMU никакими патчами фрагментацию купировать не получится. Вообще-то по большому счёту - можно. Алгоритмически. Но сложно. Алгоритмически - реализовав свою сборку мусора. Например: Периодически запуская циклы "сборки мусора" (выполняет дефрагментацию кучи). Запускаться циклы "сборки мусора" должны из критической секции. Все операции с выделенными из кучи данными - тоже только внутри этой критической секции (только пользователи кучи владеют секцией совместно, но захватывают - каждый самостоятельно). Указатели на все выделенные блоки сохраняются в некоем массиве (который корректируется сборщиком мусора). Пользователи должны периодически отпускать критическую секцию и заново захватывать её, при каждом новом запуске считывая указатель на свой выделенный блок из массива и пересчитывая заново все производные от него указатели (если нужны). Пользователи между освобождением и захватом критической секции не должны хранить никакие производные указатели от выделенного блока, только заново их генерировать при каждом новом захвате критической секции. Выполняя все эти условия, работая с указателями аккуратно, можно свести к минимуму вред от дефрагментации кучи. Но кто же из куче-пользователей станет так дисциплинированно себя и вести и писать код так аккуратно?? Вопрос ясное дело - риторический. В Яве это сделали на уровне системы - убрав указатели и позволив работать с массивами только через индексы. И добавив системный "сборщик мусора". Но это понижает эффективность кода. Quote Share this post Link to post Share on other sites More sharing options...
Axel 1 May 24, 2023 Posted May 24, 2023 · Report post Вопрос решился просто: списал переопределение менеджера у Cereal (либа сериализации). Про область применения: IoT (ближе к кофеварке, чем к марсоходу). По поводу джейсонов: они (в моем случае) разные бывают - от пары десятков байт до 2.5к (редко). Выделять память статически на максимум плохо, поскольку памяти дефицит. Поэтому, и по совокупности других обстоятельств, куча предпочтительнее. Кроме того, в определенных ситуациях (напр. если надо открыть еще один сокет) от длинных джейсонов я могу на время отписаться. Quote Share this post Link to post Share on other sites More sharing options...
jcxz 361 May 24, 2023 Posted May 24, 2023 · Report post 25 минут назад, Axel сказал: Выделять память статически на максимум плохо, поскольку памяти дефицит. Поэтому, и по совокупности других обстоятельств, куча предпочтительнее. Так если "памяти дефицит", то тем более куча - зло. Так как потребует больше памяти для такого же размера JSON. Ещё раз: В 23.05.2023 в 13:14, jcxz сказал: Макс.размер JSON-а скажем == 100 байт. Соответственно резервировать имеет смысл 100 байт. Но только при статическом выделении это и будет 100 байт потрачено, а при динамическом == 100 байт + заголовок блока + потери на фрагментацию. Quote Share this post Link to post Share on other sites More sharing options...
Axel 1 May 24, 2023 Posted May 24, 2023 · Report post Ситуации у меня в общем альтернативные (как я и писал). А "кооперативно" использовать статическую память для объектов разной природы - ИМХО, слишком высокое искусство (особенно для последующей поддержки). Так что пока - куча. Quote Share this post Link to post Share on other sites More sharing options...
mantech 142 May 24, 2023 Posted May 24, 2023 · Report post 8 часов назад, Axel сказал: Выделять память статически на максимум плохо, поскольку памяти дефицит. Ну например у меня в программе немало статических массивов, но многие одновременно не используются, поэтому прекрасно подходят для использования различными модулями непосредственно в тех же типах или через union в других. Получается экономно и практично. Quote Share this post Link to post Share on other sites More sharing options...
Axel 1 May 25, 2023 Posted May 25, 2023 · Report post Согласен. Я тоже пользую union и placement new везде, где возможно. Но в проекте, по поводу которого топик, присутствует SDK, построенный на freeRTOS, включающий lwip, А там свои дела с кучей. Ну и rapidjson, очень удобная, но внутри сильно динамическая. Quote Share this post Link to post Share on other sites More sharing options...
Axel 1 June 26, 2023 Posted June 26, 2023 · Report post Если кому-нибудь еще интересно: в конце концов все обошлось статическим буфером (нашел здесь). Пока все нравится. 1 Quote Share this post Link to post Share on other sites More sharing options...
