Application Memory Model Journey through the dark Докладчик

Application Memory Model “Journey through the dark” Докладчик: Дата: Егор Волков 4 июля 2016 года

Application Memory Model 1. 640 килобайт хватит всем 2. Память, что и куда 3. Участки памяти вашего приложения 4. Pagination и swapping 5. Application memory footprint 6. Application life cycle с точки зрения памяти 7. Heap vs. Stack 8. Garbage Collection, “stop the world” 9. Embedded systems с точки зрения памяти 10. Как сделать приложение медленным? 11. Многопоточность и память 2

Application Memory Model Каждому приложению нужна память! 1. 2. 3. 4. 5. 6. ОС владеет всем объёмом памяти, распределение и выделение памяти на ней же Приложение может при старте запросить кусок памяти и, скорее всего, оно его получит Память - ресурс разделяемый и ограниченный Производительность приложения не зависит от того, сколько памяти оно использует, а от того, КАК оно её использует Хитрые системщики придумали разные штуки, чтобы управлять памятью более эффективно. Как мы, прикладные программисты, можем свести их усилия на нет? Ручное управление памятью - вот тебе нога, а вот дробовик 3

Application Memory Model Память вашего приложения можно разделить на 4 части: 1. CODE — сегмент кода. Содержит исполняемый код. 2. DATA — сегмент статических данных. Содержит константы и прочие статические данные (вычисляемые при компиляции/сборке). 3. STACK — сегмент стека. Содержит данные для используемых функций (локальные переменные). 4. HEAP — сегмент динамических данных ("куча”). Содержит динамические данные для всей программы. 4

Application Memory Model 5

Application Memory Model Memory pagination - механизм разделения и управления памятью. 1. Физическая память делится на сегменты (страницы) фиксированного размера 2. При изменении страницы в памяти приложением, она помечается как “грязная” и должна быть записана на диск перед выгрузкой 3. Если не записать содержимое - оно исчезнет, а ОС будет очень расстроена (BSOD, kernel panic, взрыв на производстве) 4. Виртуальная память использует этот механизм чтобы обманывать программистов 5. Процесс чтения/записи и загрузки/выгрузки страниц называется свопинг (swapping) 6. Такое веселье делает возможным memory thrashing (пробуксовка) 6

Application Memory Model 7

Application Memory Model Application Memory Footprint 1. Ваше приложение занимает память. Но почему так много? 2. Подозрение на memory leak 3. Подозрение на кривую либу 4. Подозрение на кривые руки 5. Подозрение на несправедливость вселенной 6. Не аллоцируй в цикле и будешь счастлив 8

Application Memory Model Application lifecycle Память приложения изолирована от всей остальной памяти средствами ОС. 1. Приложение старутет, ОС грузит всё, что ему нужно для работы (код, данные, библиотеки) 2. Приложение получает управление, грузит всё, что считает нужным (обычно всякий мусор) 3. Приложение выделяет память и освобождает память по-ходу своего выполнения 4. Приложение запрашивает ещё памяти, ОС предоставляет (или нет) ещё памяти 5. По завершению выполнения память у приложения отбирают и ОС её утилизирует 9

Application Memory Model Heap memory versus stack memory Stack memory 1. 2. 3. 4. 5. 6. 7. 8. Heap memory 1. 2. 3. 4. 5. 6. 7. 8. Очень быстрый доступ Управляется процессором Отсутствие оверхеда Отсутствие необходимости в явной очистке Отсутствие фрагментации Только локальные переменные (function scope) Ограниченный размер (OS-specific) Нельзя изменить размер уже аллоцированной переменной 10 Относительно медленный доступ Управляется приложением и ОС Дополнительный оверхед Нужно убирать за собой самостоятельно Фрагментация уже на пороге Глобальный доступ к переменным Неограниченный размер Можно изменить уже аллоцированную переменную (realloc)

Application Memory Model Garbage collection, “stop the world” problem 1. Динамическая память подвержена фрагментации и “загрязнению”. Выход - garbage collection. 2. Garbage Collection - неэффективный костыль и большущий оверхед, но мы любим его. За что? 3. Управление памятью - бесконечная гонка оптимизаций и глупых программистов 4. “Зачем мне ваще париться? Оно же само почистит!” и другие цитаты великих людей 5. Stop the world - решение проблем в лоб 6. Разные GC для разных целей (на примере Java) 11

Application Memory Model Embedded systems с точки зрения памяти 1. Другие модели памяти для других целей 2. Оптимизируем, как в старые-добрые времена! (сделать ностальгическое лицо) 3. Регистры! Много их! А ещё, отдельная RAM и ROM! 4. EEPROM - энергонезависимо, медленно, но зато надолго* 5. Война с компилятором за каждый байт памяти, иногда - буквально. 6. Дисциплина специальной олимпиады - Java. Script on Board и Java SE Embedded (немного лучше) 7. Хардкорные и бородатые программеры пишут на ASM и руками ворочают байты и биты - “ганебна зрада” 12

Application Memory Model Как сделать приложение медленным? 1. Всегда бездумно аллоцируй большие обьекты в цикле 13

Application Memory Model Как сделать приложение медленным? 2. Думать, что стек огромен и создавать на нём большие штуки 3. Не чистить память, надеясь на ОС 4. Создавать/утилизировать очень много объектов, которые дороги/долги в создании/утилизации 5. Игнорировать то, что возвращает функция 6. Писать многопоточный код с большим количеством локов и чтением/запись в память 7. Писать на Java/C#/Ruby/Python/JS (особенно JS!)/%languagename% 14

Application Memory Model Многопоточность и память 1. 2. 3. 4. 5. 1. Многопоточное программирование - суровое настоящее Компилятор кода на Android даже не даст вам делать клёвые штуки из UI потока - “атата!”. Шожиделать? Mutex, event, conditional variable - synchronization primitives Функциональное программирование и иммутабельность немного спасает положение Теперь нужно думать не только о памяти, но и об обращениях к ней Один неверный шаг и всё взорвётся - sad, but true 15

Application Memory Model Каждому приложению нужна память! 1. 2. 3. 4. 5. 6. Не получится бездумно везде тыкать аллокации и верить в то, что вам повезёт Компиляторы и garbage collector’ы становятся лучше с каждым днём, а программисты - хуже Защита от дурака в современных IDE Помним о сущности памяти как ресурсе - она одна, приложений много Многопоточность - на порядок больше проблем и возможностей Извечный “CPU-2 -memory” tradeoff и реальность 16

Application Memory Model Сейчас самое время задать свой вопрос! 17

Application Memory Model Спасибо за внимание! Докладчик: Дата: Егор Волков 7 июля 2016 года