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

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

#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)?

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

Источник

3 ответа

Решение

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

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

Источник

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

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

Источник

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

PDF презентация

Источник
Другие вопросы по тегам