aboutsummaryrefslogtreecommitdiffstats
path: root/contrib/restricted/libffi/configs
diff options
context:
space:
mode:
authormorozov1one <morozov1one@yandex-team.com>2024-11-29 20:28:24 +0300
committermorozov1one <morozov1one@yandex-team.com>2024-11-29 20:37:50 +0300
commit0924e1c53b7aec2c5efefe89499154b0a7e902f7 (patch)
treed41153892fac73aeed483b850203444f747bf54e /contrib/restricted/libffi/configs
parentc67888be3cb9ffde249bcc0ec11b1a2cde58f60b (diff)
downloadydb-0924e1c53b7aec2c5efefe89499154b0a7e902f7.tar.gz
Upgrade mimalloc to 1.8.7
Ниже описал существенные изменения в поведении, которые я заметил (в сравнении с версией 1.7.2, которая лежит в контрибах сейчас) Полный changelog можно посмотреть в [readme.md](http://readme.md) * Поменялся дефолт у [опции](https://github.com/microsoft/mimalloc/blob/9cae0d31cd28476664dbaa6e4e6940b9d900842a/src/options.c#L109), определяющей то, как неиспользуемая память возвращается в систему. В старых версиях по умолчанию использовался madvise с флагом MADV_FREE, в свежих версиях же используется MADV_DONTNEED. Это может вызвать неожиданные изменения (в худшую сторону) на графиках потребляемой анонимной памяти (), хотя по факту потребление должно быть \+- одинаковым * Алгоритм работы аллокатора претерпел некоторые изменения. Например, мы споткнулись об то, что в новой версии mimalloc выделяет себе 1Gb (размер задается [опцией](https://github.com/microsoft/mimalloc/blob/2765ec93026f445cad8f38e6b196dd226a1f6e61/src/options.c#L87)) памяти при первой же аллокации. Само по себе это мало на что влияет, но неприятности могут случиться, если звать в начале программы mlockall commit_hash:dc6d945c1776c874e554f94b705c4e446b0a11d8
Diffstat (limited to 'contrib/restricted/libffi/configs')
0 files changed, 0 insertions, 0 deletions