Я думаю, что ваш проект слишком амбициозен. Например, замена существующей инфраструктуры GV JVM на управление распределением / освобождением памяти, вероятно, повлечет за собой существенное переписывание кодовой базы собственного кода JVM И реорганизацию библиотеки классов Java.
(Знаете ли вы, что извлечение исходного репозитория Java 11 OpenJDK составляет 2,5 Гбайт? Там много кода. Посмотрите, прежде чем прыгать.)
Вы спросили:
Было бы целесообразно использовать ручной сборщик мусора вместо автоматического сбора мусора?
На мой взгляд, нет:
Как было продемонстрировано давно (см. Классическую статью Zorn), для больших приложений автоматический ГХ выполняется так же быстро (если не быстрее), как управление хранением данных с помощью malloc / free с помощью интеллектуальных указателей.
Вся библиотека классов Java разработана в предположении, что GC является автоматическим и эффективным. Если вы измените это, то большая часть текущего дизайна API будет проблематичной; т. е. это приведет к утечке объектов кучи.
Однако, если вы вложите в проект около 10 человеко-лет квалифицированных разработчиков, вы можете получить другой ответ. (И, возможно, совсем другой язык программирования!)
Распространено ли использование ручного ГХ в промышленности?
С Java это неслыханно.
В таких языках, как C / C ++, которые не были написаны с учетом автоматического GC, все еще широко используется ручное управление хранением. (Но не универсальный. Читайте о консервативном сборщике Бёма .)
Или программисты везде используют автоматический сборщик мусора?
С Java, да.
Во многих других языках программирования да. Но не на всех языках.
Справка:
- «Измеренная стоимость консервативного сбора мусора» Бенджамина Г. Цорна, Опубликовано в Softw., Pract. Эксперти. 1993. DOI: 10.1002 / spe.4380230704