Если вернуться к показанным в публикации фрагментам кода из исходника memorysupervisor.cpp можно увидеть, что показанные там new операторы перехватываются. Как я понимаю это результат того, что их реализация выполнена через malloc/calloc. К сожалению не представил исполнение delete оператора. Но имею подозрения, что его реализация базируется на использовании вызова free(). Поэтому установление крючков — перехватчиков к malloc/calloc/realloc/free обеспечивает перехват и запросов по new/delete.
Возможно я не все понял, но два вопроса все-таки возникают.
1) при выявлении причин нехватки памяти время исполнения не столь критично в этом режиме (собственно алгоритмы берут на 2-3 порядка больше времени). Важны результаты, а именно: какая память в приложении не освобождается и накапливается.
2) как я понимаю предлагаемый аллокатор контролирует и включает в отчет утечки памяти и пр.? Если это так и он внешний, то какой размер отчета я получаю по всему приложению? А это не требуется. В подавляющем большинстве случаев известен один (или несколько) исполняемых потоков операций (not threading), где необходимо искать проблему. Поэтому локальные вставки макросов и дают урезанный лог. Конечно, вопрос спорный. Но вроде как такая практика приносит свои положительные результаты наряду с высказанными вами негативными сторонами: замедление, инструментовка исходников для извлечения данных о памяти
Действительно представленное описание было ориентировано на использование средств встроенного контроля в контексте однопоточного исполнения. Но ничто не ограничивает в указанных функциях установить блокировки вида:
#include
#include
#include
#include
….
std::mutex g_lock;
void ProtectedFunction()
{
g_lock.lock ();
//делаем в защищенном режиме.
g_lock.unlock();
}
… и обрабатывать запросы к памяти в защищенном режиме.
В отношении кастомного аллокатора памяти – нет вопросов, если выполняется разработка нового программного обеспечения. В тех же случаях, когда сопровождается и развивается приложение с глубокой “историей” и большим контингентом пользователей на такой риск вряд ли кто решится.
В отношении высказанного (правда ничем не подтвержденного) утверждения о неэффективности описанного подхода можно лишь заметить, что последняя картинка в публикации относится к профилированию динамической памяти в очень сложном приложении, в котором на пятые сутки непрерывного исполнения обнаруживалась ситуация исчерпания ресурсов памяти с последующим аварийным завершением. Это простенькое средство контроля позволило выявить причины.
Так что, не претендуя на универсальность это средство приносит пользу.
1) при выявлении причин нехватки памяти время исполнения не столь критично в этом режиме (собственно алгоритмы берут на 2-3 порядка больше времени). Важны результаты, а именно: какая память в приложении не освобождается и накапливается.
2) как я понимаю предлагаемый аллокатор контролирует и включает в отчет утечки памяти и пр.? Если это так и он внешний, то какой размер отчета я получаю по всему приложению? А это не требуется. В подавляющем большинстве случаев известен один (или несколько) исполняемых потоков операций (not threading), где необходимо искать проблему. Поэтому локальные вставки макросов и дают урезанный лог. Конечно, вопрос спорный. Но вроде как такая практика приносит свои положительные результаты наряду с высказанными вами негативными сторонами: замедление, инструментовка исходников для извлечения данных о памяти
#include
#include
#include
#include
….
std::mutex g_lock;
void ProtectedFunction()
{
g_lock.lock ();
//делаем в защищенном режиме.
g_lock.unlock();
}
… и обрабатывать запросы к памяти в защищенном режиме.
В отношении кастомного аллокатора памяти – нет вопросов, если выполняется разработка нового программного обеспечения. В тех же случаях, когда сопровождается и развивается приложение с глубокой “историей” и большим контингентом пользователей на такой риск вряд ли кто решится.
В отношении высказанного (правда ничем не подтвержденного) утверждения о неэффективности описанного подхода можно лишь заметить, что последняя картинка в публикации относится к профилированию динамической памяти в очень сложном приложении, в котором на пятые сутки непрерывного исполнения обнаруживалась ситуация исчерпания ресурсов памяти с последующим аварийным завершением. Это простенькое средство контроля позволило выявить причины.
Так что, не претендуя на универсальность это средство приносит пользу.