Eclipse возвращает кучу обратно в систему

Нашел решение. Я переключил Java на использование сборщика мусора G1, и теперь параметры HeapFreeRatio работают как положено. Поэтому я использую эти параметры в eclipse.ini:

-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
-XX:MinHeapFreeRatio=5
-XX:MaxHeapFreeRatio=25

Теперь, когда Eclipse съедает более 1 ГБ ОЗУ для сложной операции и переключается обратно на 300 МБ после сборки мусора, память фактически освобождается обратно операционной системе.

Вы можете пойти в Preferences -> General и проверить Show heap status. Это активирует хороший вид на вашу кучу в углу Eclipse. Что-то вроде этого:

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

Куча Java — это не что иное, как большая структура данных, управляемая в пространстве кучи процесса JVM. Две кучи являются логически отдельными объектами, даже если они занимают одну и ту же память.

JVM находится во власти реализаций хост-системы malloc(), которая выделяет память из системы, используя brk(). В системах Linux (и в Solaris тоже) память, выделенная для кучи процесса, почти никогда не возвращается, в основном потому, что она становится фрагментированной, а куча должна быть непрерывной. Это означает, что память, выделенная процессу, будет монотонно увеличиваться, и единственный способ уменьшить ее размер — вообще не выделять ее.

-Xms и -Xmx сообщают JVM, как заранее определить размер кучи Java, что приводит к выделению памяти процесса. Java может собирать мусор до тех пор, пока солнце не выгорит, но эта очистка является внутренней для JVM, и память процесса, поддерживающая ее, не возвращается.

Разработка из комментария ниже:

Стандартный способ для программы, написанной на C (в частности, для JVM, работающей с Eclipse), для выделения памяти — это вызвать malloc(3), который использует предоставленный ОС механизм для выделения памяти процессу, а затем управляет отдельными выделениями в рамках этих выделений. Детали того, как работают malloc() и free(), зависят от реализации.

В большинстве разновидностей Unix процесс получает ровно один сегмент данных, представляющий собой непрерывную область памяти с указателями на начало и конец. Процесс может настроить размер этого сегмента, вызвав brk(2) и увеличив конечный указатель, чтобы выделить больше памяти, или уменьшив его, чтобы вернуть его системе. Только конец можно отрегулировать. Это означает, что если ваша реализация malloc() увеличивает сегмент данных, соответствующая реализация free() не может его уменьшить, если только не определит, что в конце есть свободное место, которое не используется. На практике огромный кусок памяти, выделенный с помощью malloc(), редко оказывается в самом конце сегмента данных, когда вы его free(), вот почему процессы имеют тенденцию к монотонному росту.