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

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

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

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

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

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

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

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

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

Можете ли вы получить JVM с открытым исходным кодом и отключить ее сборщик мусора, например Sun's Hotspot ?

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

public myClass {

      public void aMethod() {

            String text = new String("xyz");

      }

}

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

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

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

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

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

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

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

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

Если бы у меня была такая проблема, я бы взял Jikes Research Virtual Machine от IBM, потому что:

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

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