JEP 316: Heap Allocation on Alternative Memory Devices
Размещение кучи на альтернативных устройствах памяти
| Ответственный | Kishor Kharbas |
| Тип | Feature |
| Область | JDK |
| Статус | Closed / Delivered |
| Выпуск | 10 |
| Компонент | hotspot / gc |
| Обсуждение | hotspot dash dev at openjdk dot java dot net |
| Трудоёмкость | M |
| Длительность | M |
| Рецензенты | Mikael Vidstedt |
| Одобрен | Mikael Vidstedt, Vladimir Kozlov |
| Создан | 2016/12/13 19:31 |
| Обновлён | 2020/10/02 01:16 |
| Задача | 8171181 |
Аннотация
Дать HotSpot VM возможность размещать кучу объектов Java на указанном пользователем альтернативном устройстве памяти, например на NV-DIMM.
Мотивация
Дешёвая память NV-DIMM становится доступной, поэтому будущие системы могут получить гетерогенную архитектуру памяти. Один из примеров такой технологии — Intel 3D XPoint. В такой архитектуре, помимо DRAM, будет один или несколько типов памяти, отличной от DRAM, с другими характеристиками.
Этот JEP нацелен на альтернативные устройства памяти с той же семантикой, что и у DRAM, включая семантику атомарных операций. Поэтому их можно использовать для кучи объектов вместо DRAM без каких-либо изменений в коде существующих приложений. Все остальные структуры памяти, такие как куча кода, metaspace, стеки потоков и т. д., по-прежнему будут находиться в DRAM.
Некоторые сценарии использования этого предложения:
-
Когда запущено несколько JVM, у некоторых из них, например у демонов, служб и т. д., приоритет ниже, чем у остальных. У NV-DIMM задержка доступа, вероятно, будет выше, чем у DRAM. Низкоприоритетные процессы могут размещать кучу в памяти NV-DIMM, и тогда высокоприоритетным процессам достанется больше DRAM.
-
Приложениям для больших данных, базам данных в памяти и подобным приложениям требуется всё больше памяти. Такие приложения могли бы размещать кучу в NV-DIMM, поскольку ёмкость NV-DIMM, вероятно, будет больше, а стоимость ниже, чем у DRAM.
Описание
Некоторые операционные системы уже предоставляют доступ к памяти, отличной от DRAM, через файловую систему. Примеры: NTFS DAX mode и ext4 DAX. Отображённые в память файлы в этих файловых системах обходят страничный кэш и напрямую отображают виртуальную память на физическую память устройства.
Чтобы разместить кучу в такой памяти, мы можем добавить новый параметр -XX:AllocateHeapAt=<path>. Этот параметр будет принимать путь в файловой системе и с помощью отображения в память размещать кучу объектов на устройстве памяти. Этот JEP не предполагает совместного использования энергонезависимой области несколькими работающими JVM или повторного использования той же области при последующих запусках JVM.
Существующие флаги, связанные с кучей, такие как -Xmx, -Xms и т. д., а также флаги, связанные со сборкой мусора, будут работать как раньше.
Для безопасности приложения реализация должна гарантировать, что файлы, созданные в файловой системе:
- Защищены правильными правами доступа, чтобы другие пользователи не могли к ним обращаться.
- Удаляются при завершении приложения в любом возможном сценарии.
Тестирование
Для тестирования не обязательно нужна специальная память: его можно проводить в файловых системах в памяти, таких как ramfs или tmpfs.