Детерминированная сборка мусора в JVM

Интересно, есть ли случаи, когда JVM Hotspot или любые другие JVM могут детерминистически собирать мусор. Я знаю об анализе побега, но задаюсь вопросом, работает ли он для выделенных кучи объектов. То, что я имею в виду в коде C++, такие как это дает детерминированный сбор мусора от кучиДетерминированная сборка мусора в JVM

#include <vector> 
int main(int argc, char*argv[]){ 
    std::vector<double> v_somevector; 
} // std::vector::~vector() is called determinitically

Конечно, в Java что-то вроде

. 
. 
. 
private double ma() throws Exception{ 
    double result = 0.0; 
    final double[] closes = new double[100000]; 
    //perform some calculation using the closes array above 
    return result; 
} // At this point why shouldn't closes be deterministically garbage collected (as in immediately)?

Должен быть детерминированным в мусоре, собирающего массив закрывается. Для того, что кажется, анализ escape-анализа, по-видимому, фокусируется на возможности выделения закрывающего массива в стеке, но даже если он выделен в кучу, в этом случае я не вижу, почему он не может быть собран при выходе из ma() с)

источник

2013-12-02 Michael

Это, безусловно, может быть; спецификация Java не запрещает это. Это просто оставляет вопрос о сборке мусора полностью до реализации. JVM даже не должен вообще реализовывать сборку мусора!

Причина в том, что существует несколько методов, которые может использовать JVM, которые будут вероятностно более эффективными, чем такое синхронное распределение, о котором вы говорите, например, кучи поколений и параллельные метки и развертки , Вы могли бы свободно реализовывать логику, о которой говорите в своей собственной виртуальной машине, но профилирование продемонстрировало, что для многих бизнес-нагрузок большая часть использования ЦП в программах на С ++ берется за строительство и уничтожение объектов и подходов, таких как кластеры генерации, упрощают управление памятью.

источник

2013-12-02 13:28:31 chrylis

Мне удавалось писать приложения, которые не останавливались на Full GC в течение нескольких недель, но не могут не думать, что могут быть ситуации, когда отсрочка GC может быть нежелательной. Поэтому, возможно, это как вариант виртуальной машины будет желательным. – Michael

@Michael Обратите внимание, что синхронное, исправленное управление памятью также может вызвать внезапные задержки - например, если куча слишком фрагментирована и нуждается в некоторой консолидации, или если вы выпустили ссылку на большой связанный список/бинарное дерево, транзитивно вызывающее много ссылок чтобы достигнуть нуля сразу. –

@MarkoTopolnik Хорошая точка. – Michael

Я вспомнил несколько лет назад JRockit Real Time JDK. Не уверен, что он соответствует современным спецификациям.

PDF presentation

источник

2013-12-02 13:48:07 chro

Что вы говорите не столько детерминированным в нетерпеливый сбора мусора, и если JVM действительно лечить вас к нему, вы бы пожалели ваше желание. Ожидаемый GC неэффективен как на стороне выделения, так и на стороне распределения: он заставляет среду выполнения обрабатывать память так же гранулированно, исключая многие возможности оптимизации и вызывая фрагментацию кучи.

Если вы действительно заботитесь о производительности, то вы хотите, чтобы ваш GC-ing сделал оптом, и это именно то, что делает HotSpot.

источник

2013-12-02 14:00:02

Детерминированная сборка мусора в JVM

ответ

Смежные вопросы