JVM без сборки мусора

Question

Я читал во многих потоках, что невозможно отключить сборку мусора в JVM от Sun. Однако для целей нашего исследовательского проекта нам нужна эта функция. Кто-нибудь может порекомендовать реализацию JVM, которая не имеет сборки мусора или которая позволяет отключить ее? Спасибо.

Answer 1

Я хотел найти быстрый способ сохранить все объекты в памяти для простого начального доказательства концепции.

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

Это будет быстрее и проще, чем модификация JVM.

---

^{(Оглядываясь назад, это может не сработать. Я смутно припоминаю свидетельства, свидетельствующие о том, что JVM не всегда всегда учитывает настройку -Xms, особенно если она была действительно большой. Тем не менее, этот подход стоит попробовать, прежде чем пытаться использовать более сложный подход, например, модифицировать JVM.)}

^{Кроме того, все это кажется мне ненужным (даже контрпродуктивным) для того, чего вы на самом деле пытаетесь достичь. GC не будет выбрасывать объекты, если они не являются мусором. И если они мусор, вы не сможете их использовать. И производительность системы с отключенным / отключенным GC не будет показывать, как будет работать приложение real .}

Answer 2

В зависимости от ваших потребностей это может сработать:

Используя опцию -Xbootclasspath, вы можете указать собственную реализацию классов API. Затем вы можете, например, переопределить реализацию Object и добавить в конструктор globalList.add(this), чтобы предотвратить сборку мусора. Это, конечно, хак, но для простого кейса этого, пожалуй, достаточно.

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

Answer 3

Sun JVM не имеет такой опции. AFAIK, ни одна другая JVM не имеет этой опции.

Вы не указали, что именно вы пытаетесь достичь, но у вас есть один из двух вариантов: либо использовать профилировщик, и точно увидеть, что делает GC, чтобы вы могли учитывать его эффекты. Другой - скомпилировать одну из JVM из исходного кода и отключить GC оттуда.

Answer 4

вопрос старый, но для тех, кто может быть заинтересован, есть предложение

Разработать GC, который обрабатывает только распределение памяти, но не реализует какой-либо реальный механизм восстановления памяти. Когда доступная куча Java будет исчерпана, выполните упорядоченное завершение работы JVM.

Проект JEP: Эпсилон GC: Произвольно низкий сборщик мусора (не)

Answer 5

На самом деле существует грязный хак, чтобы временно приостановить сборку мусора. Сначала создайте фиктивный массив в Java. Затем в JNI используйте функцию GetPrimitiveArrayCritical, чтобы получить указатель на массив. Sun JVM отключит GC, чтобы гарантировать, что массив никогда не перемещается и указатель остается действительным. Чтобы снова включить GC, вы можете вызвать функцию ReleasePrimitiveArrayCritical для указателя. Но это очень зависит от реализации, так как другие виртуальные машины могут прикреплять объект вместо полного отключения GC. (Проверено для работы на Oracle JDK 7 и 8)

Answer 6

Вы можете отключить GC только в том случае, если он на самом деле не нужен (в противном случае вашему приложению не хватило бы памяти), и если вам не нужен GC, он все равно не должен запускаться.

Самый простой вариант - не сбрасывать какие-либо объекты, это предотвратит выполнение GC (и установит максимальный объем памяти очень высоким, чтобы вы не закончили).

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

Answer 7

Взгляните на JRockit JVM от Oracle . Я видел очень хорошую почти детерминированную производительность на оборудовании Intel с этой JVM, и вы можете проследить за временем выполнения, используя утилиту Mission Control , чтобы увидеть, насколько хорошо она работает.

Хотя вы не можете полностью отключить GC, я считаю, что вы можете использовать опцию -Xnoclassgc , чтобы отключить коллекцию классов. GC может быть настроен на минимизировать задержку за счет увеличения потребления памяти. Вам может потребоваться лицензия, чтобы снизить задержку настолько, насколько вам нужно, если вы идете по этому маршруту.

Существует также версия JVM JRockit в реальном времени, но я не думаю, что есть бесплатная версия для разработчиков.

Answer 8

Можете ли вы получить JVM с открытым исходным кодом и отключить его GC, например Точка Солнца ?

Если бы не было сборщика мусора, какую семантику такого кода вы бы ожидали?

public myClass {

      public void aMethod() {

            String text = new String("xyz");

      }

}

В отсутствие GC ни один новый элемент, имеющий ссылку на область стека, никогда не сможет быть возвращен. Даже если ваши собственные классы могут решить не использовать локальные переменные, подобные этой, или использовать только примитивные типы, я не понимаю, как вы могли бы безопасно использовать любую стандартную библиотеку Java.

Мне было бы интересно узнать больше о вашем сценарии использования.

Answer 9

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

Мой (полностью ограниченный) опыт подсказывает мне, что виртуальная машина по умолчанию крайне ленива и крайне неохотна для запуска GC.

предоставление -Xmx 16384M (или чего-то подобного) и обеспечение того, чтобы ваш предмет исследования оставался значительно ниже этого предела, может дать вам среду, которую вы хотите получить, хотя даже тогда это, очевидно, не будет гарантировано.

Answer 10

Если бы у меня была эта проблема, я бы получил виртуальную машину IBM Jikes Research , потому что:

• Система времени выполнения написана на самой Java (со специальными расширениями)
• Все это было разработано как исследовательский инструмент, и его относительно легко настроить.

Вы не можете отключить GC навсегда, потому что Java-программы do выделяют ив конечном итоге вам не хватит памяти, но вполне возможно, что вы можете отложить сборщик мусора на время эксперимента, сказав JVM не начинать сбор, пока куча не станет действительно большой.(Этот трюк может сработать и на других JVM, но я не знаю, где найти ручки для вращения.)