Ответ 1
Зависит от того, что вы подразумеваете под "достаточным объемом памяти". Для простой "атаки" фрагментации:
-
Сделайте squillion
small
распределения до тех пор, пока не сработает [*]. -
Теперь отсортируйте их по порядку адреса [**].
-
Бесплатные 100 альтернативных распределений.
-
Попытка выделить
100*small
байт.
Скорее всего, распределитель не сможет найти непрерывную память для удовлетворения этого. Если у него размер страницы small
и большое количество виртуальных адресных пространств по сравнению с физической памятью, то он может изменить порядок действий, но для этого требуется, чтобы MMU располагал преимуществами стратегии анти-фрагментации распределитель.
Если по "достаточной доступной памяти" вы имеете в виду блок памяти large
, который раньше был смежным блоком, был разделен на несколько распределений, все из которых были освобождены, и теперь распределитель рассматривает его как отдельные блоки и поэтому не удается выделить large
байт, тогда нет, я не думаю, что вы можете заставить произвольный блок-распределитель блокировать объединение блоков. Некоторые распределители или другие могут сделать гораздо больше работы, чем Windows, кажется, делает в этом другом вопросе, чтобы гарантировать, что смежные свободные блоки всегда объединены.
[*] Возможная проблема: чрезмерные фиксаторы памяти могут не сработать, вы просто получите segfault или ваш процесс будет убит. В таких системах вам может потребоваться отслеживать, сколько памяти доступно.
[**] Возможная проблема - в C и С++, operator<
не гарантируется работа. Но почти во всех системах он делает, а в С++ там std::less
тоже.