Использование огромных страниц и DirectByteBuffer в Java HotSpot JVM на Linux

Question

Что я хотел бы сделать

мне нужно использовать прямую память, чтобы избежать GC движущихся вещей вокруг. Я хотел бы включить огромные страницы для них.

До сих пор

флаг -XX: + UseLargePages отлично работает при использовании буфера кучи (не прямые ByteBuffers), но больше не работает при использовании DirectByteBuffers. Я также пытался использовать MappedByteBuffers и файловую систему hugetlbfs. Это работает, но вызывает ряд проблем, поэтому я ищу другое решение.

Config CentOS выпуск 6.3, точка доступа, jdk1.7

[EDIT]

Глядя на горячих точек исходного кода, они используют таНос для выделения памяти с небезопасными, были Shmat/shmget или mmap потребуется для использования огромных страниц.

[EDIT] Почему не куча памяти

Мы в контексте NUMA, для в базе данных памяти, с большим количеством долгоживущих объектов. JVM не разбивает старый ген, когда флаг UseNUMA включен. Использование прямой памяти позволяет нам поддерживать память вблизи потоков, которые ей нужны.

Бенчмаркинг, очевидно, сыграл огромную роль в решении использовать DirectByteBuffers. Я не спрашиваю, должен ли я использовать DirectByteBuffer или нет, я скорее ищу ответ на свой вопрос.

Answer 1

Для тех, кто заинтересован, ссылка на oracle bug report

ссылка на соответствующий openJDK ticket. Закрыто, пока не исправит. В Linux функция THP может помочь, даже несмотря на то, что она имеет свои собственные проблемы.

Answer 2

У вас есть эталон, который однозначно показывает, что пересечение GC является узким местом для вашего приложения?

Если нет, НЕ ДЕЛАЙТЕ ЭТО.

Если да, добавьте ссылку на нее, чтобы ее можно было пересмотреть.

Такого рода эффекты низкого уровня, как известно, трудно выделить в качестве причины проблем с производительностью, и очень возможно, тратить много времени на поиск фантомных эффектов & получения раствора, который пытается обойти JVM & только результаты в гораздо худшем исполнении, чем было бы получено, если бы вы застряли по проторенному пути.

Answer 3

Обходным путем является использование JNI для выделения памяти на C с использованием любого способа, который вы хотите, и возврата ByteBuffer. См. NewDirectByteBuffer. Этот подход имеет дополнительное преимущество, которое вы можете детерминистически освободить память.