Linux оптимистический malloc: будет новый всегда бросать когда из памяти?
В зависимости от сложности Вашего продукта непрерывная интеграция может или не может быть способным выполнением полный набор тестов.
Предполагают, что Cisco, тестирующая маршрутизатор с буквально 1000-е различных установок, тестирует. Выполнять полный набор тестов на некоторых продуктах занимает время. Иногда недели. Таким образом, Вам нужны сборки в различных целях. Ночная сборка может быть основанием для более полного набора тестов.
5 ответов
Это зависит; вы можете настроить параметры перегрузки ядра с помощью vm.overcommit_memory.
Херб Саттер несколько лет назад обсуждал, как такое поведение фактически не соответствует стандарту C ++ :
В некоторых операционных системах, включая, в частности, Linux, распределение памяти всегда выполняется. Полная остановка. Как распределение всегда может быть успешным, даже если запрошенная память действительно недоступна? Причина в том, что само выделение просто записывает запрос памяти; под покрывает, (физическая или виртуальная) память фактически не передается запрашивающему процессу с реальным резервным хранилищем до тех пор, пока память не будет фактически использована.
«Обратите внимание, что если new напрямую использует возможности операционной системы, тогда новый всегда будет успешным, но любой более поздний невинный код вроде buf [100] = 'c'; может бросить, потерпеть неудачу или остановиться. С точки зрения Стандартного C ++ оба эффекта несовместимы, потому что стандарт C ++ требует, чтобы, если new не может выделить достаточно памяти, он должен завершиться ошибкой (это не так), а этот код вроде buf [100] = 'c' не должен не генерировать исключение или иначе завершаться ошибкой (это может быть). "
Вы не можете справиться с этим в своем программном обеспечении, в чистом виде.
Для вашего приложения вы получите совершенно правильный указатель. Как только вы попытаетесь получить к нему доступ, он сгенерирует ошибку страницы в ядре, ядро попытается выделить для него физическую страницу, а если не сможет ... бум.
Но, как вы видите, все это происходит внутри ядра, ваше приложение этого не видит. Если это критическая система, вы можете полностью отключить избыточную фиксацию в системе.
Я думаю, что malloc все еще может возвращать NULL. Причина в том, что существует разница между доступной системной памятью (RAM + swap) и объемом адресного пространства вашего процесса.
Например, если вы запрашиваете 3 ГБ памяти у malloc на стандартном Linux x86, он обязательно вернет NULL, поскольку это невозможно, учитывая объем памяти, выделенный приложениям пользовательского пространства.
Простите, если я ошибаюсь, но не пытаюсь обнулить выделенную память, этого будет достаточно, чтобы гарантировать, что вы получить каждый запрошенный байт? Или даже просто записывая в последний байт, это вызовет исключение, если память действительно не ваша?
Если это правда, вы можете просто попробовать записать в последний (и первый?) Байт памяти и посмотреть, работает ли он нормально, а если нет, вы можете вернуть null из malloc.
Да, есть одна гарантия, что новый со временем выбросит. Независимо от превышения лимита адресное пространство ограничено. Так что, если вы продолжите выделять память, рано или поздно у вас закончится адресное пространство, и new будет вынужден выбросить.