Написать реалтаймовый сборщик мусора для Java

https://en.wikipedia.org/wiki/Garbage-first_collector

Мне непонятен статус сборщика G1.
ИИ пишет: «G1 доступен только в Oracle GraalVM (Enterprise Edition). В Community Edition Native Image он, увы, недоступен.»
Но как это проверить? «The G1 GC (only available with GraalVM Enterprise Edition)» (оттуда)

Зачем, если в жабе уже есть сборщик мусора с предсказуемой задержкой искаропки?

Потому что тяжело сделать троллейбус из гнилой буханки, наверное.

Надо чтобы не только был, но и чтобы я знал, как его использовать.

ИИ говорит мне: OpenJDK (LTS) + Shenandoah + Project Leyden

И чего, что делать-то?

java -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -jar myapp.jar

Проблемы нет. Вы фантазируете. Сообщество не примет этого всерьёз. Но отмечаю, что сборщики мусора для Java разрабатывает фирма Oracle. Ей и предлагайте. Неподдержмывемая сообщная Java никому не нужна.

А можно пояснить какие такие перед тобой стоят задачи, где нужен реалтаймовый gc?

то могли бы переписать на Rust?

Могли бы несомненно и скорее всего попытаются, но людей способных с первого раза на расте даже сделать корректный разбор аргументов rm, как мы выяснили в соответствующей теме - нет. Так что, боюсь, это не рентабельно.

да всё есть уже.
тут jenkins пытались в магию, например - https://www.jenkins.io/blog/2016/11/21/gc-tuning/#the-magic-settings/

да всё есть уже

«G1 GC settings»…

надо различать «есть у них, и есть у нас»

Надо чтобы не только был, но и чтобы я знал, как его использовать.

Да вроде ничего сложного

 -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC 

Это только для использования в крылатых ракетах. Когда долетит до места назначения, там уже неважно будет, что и как было занято.

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

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

Как называть Shenandoah на русском языке? «Шенандоа»? Какие есть книжки на русском языке, которые можно прочитать?

Сходил по ссылке, предлагаю самоучитель индейского.

Сообщество - это ты. Ты не написал реалтаймовый сборщик, хотя статьи все доступны.

вангую что там openjdk.
чего тебе ещё надо?(с) мягонький вариант

*индийского?

В чём такая проблема для сообщества?

а сообщество вообще не чешется?

И так каждый раз, в каждой теме нытьё… В чём такая проблема взять и начать писать, а не чесаться и кивать каждый раз на сообщество?

А сообщество - это кто?

Шенандо́а — слово имеет индейское происхождение.

Проблема уборки мусора в Java решена созданием C++20.

Проблема уборки мусора в Java решена созданием C++20.

мысль не ясна.

«C++23 окончательно удалил экспериментальную инфраструктуру, которая когда-то закладывалась для возможной поддержки GC в будущем»

Вы фантазируете.

Почему человек имеет право фантазировать, а другие люди не должны запрещать это делать?

LLM: «фундаментальные принципы:

• самоопределения личности
• свободы мысли
• защиты внутреннего мира человека от внешнего вмешательства

статья 18 Всеобщей декларации прав человека
(принята Генеральной Ассамблеей ООН 10 декабря 1948 года)
закрепляет право на свободу мысли, совести и религии.

Статья 29 Конституции Российской Федерации провозглашает:
„Каждому гарантируется свобода мысли и слова”.

Анри Бергсон связывал фантазию с „жизненным порывом” — универсальной творческой силой, лежащей в основе эволюции и свободы мышления.»

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

В общем, предлагаю сделать «управление памятью на основе правил».

Нет! Только хаос, только анархия!

А какую задачу ты пытаешься решить?

Почему какая-то IBM может и сделала

Что ты имеешь ввиду? Если их JVM, то OpenJ9 давно отдана в сообщество под Apache лицензией.

Ну типа, зачем на Java продолжать пейсать при наличии чего-то типа современного C++20 или там Rust.

Ну тут такое дело… Управление памятью никуда не девалось, и оно останется с нами навсегда.

C++ предлагает какой-то механизм отслеживания жизни объектов. Но единственный ли такой алгоритм? Подходит ли он для любых техник моделирования (парадигм программирования)? Как это соотносится с тем, что как минимум в Java и Lisp существует другой подход?

В общем, всё меняется, C++ не финальная неулучшаяема высота, и изобретут более продвинутые подходы и алгоритмы. И тут вопрос - почему это должны сделать некие «они», а не русские люди?

ЕМНИП, суть в том, что есть GraalVM Community Edition + Native Image. Вот это вот барахло выдаёт бинарники только со встроенным SerialGC. Хочешь G1 GC в бинарнике --- плати.

А чего тогда вот эти все вокруг говорят, что всё есть и всё встроено?

Ничего, получается, нет. И всё недоделанное.

Ещё раз: «в бинарнике». Здесь это ключевой момент. При классической работе через JVM доступные все GC.

Пишите на Ada, там можно легко все в «реалтайм». 8)

Ещё раз: «в бинарнике». Здесь это ключевой момент.

Ну правильно, в докер бинарником и суют, и никак иначе.

При классической работе

Ой, всё…

Если на C++ пишут, то могли бы переписать на Rust?

чтобы что?

C++ предлагает какой-то механизм отслеживания жизни объектов.

Сила С++ в том, что он ничего не предлагает и не навязывает.

И тут вопрос - почему это должны сделать некие «они», а не русские люди?

Это делают русские люди, только они «там» :)

А можно пояснить какие такие перед тобой стоят задачи, где нужен реалтаймовый gc?

HFT например, только там gc обычно отключают совсем :)

Я имею в виду таких русских людей, которые работают на русском языке.
Те, которые там, не могут позволить себе такой роскоши.

Для таких я могу порекомендовать русский язык программирования Кумир: https://qumir.dev/

Я имею в виду таких русских людей, которые работают на русском языке.

Вам прямая дорога в 1С! Так же ходят слухи о рывке в ПГУ переведшем синтаксис js на русский язык, но это думается мне прорыв.

Про русскую ОС забыли и эльбрусы с байкалами, а то как-то не очень патриотично получается

Реализовать сборщик мусора, пригодный для полноценного практического применения это очень сложная и наукоёмкая задача. На отдельных нюансах алгоритмов сборки мусора докторские защищают.

Сборка мусора и реалтайм это вообще практически противоположные понятия. Срастить их это задача сложная в квадрате.

И при всём при этом реалтайм очень мало кому нужен. А кому нужен - те, как правило, пользуются более специализированными языками программирования.

Вот по всем этим причинам «сообщество» и не написано реалтаймовый сборщик мусора для Java.

Я, кстати, не слыхал, чтобы в graalvm был реалтаймовый сборщик мусора. У graalvm лицензия gpl. В общем с постановкой вопроса ты, кажется, тоже слегка промазал. Я не знаю, что там у IBM, про реалтайм сборщик мусора я слыхал только от Azul.

это очень сложная и наукоёмкая задача

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

Дай, что ли, определение науки.

Наука это получение новых знаний об устройстве мира, выявление законов мироздания. И вот в этих словах надо определить что в вашем исследовании объект исследования, а что предмет.

А разработкой алгоритмов по большей части математики занимаются. Вообще говоря, объектом исследования в данном случае являются информационные процессы и алгоритмы, а предметом — их разрешимость, сложность, корректность и структура. В СССР науку об информационных процессах назвали информатикой, а на Западе — Computer Science. Программирование же — это прикладная дисциплина.

ClaudeAI:

Хороший вопрос — это одна из тех тем, где дьявол в деталях. Realtime GC для Java — задача решаемая (есть же Azul Zing, IBM Metronome, JamaicaVM), но проблемы там фундаментальные.

Главная проблема — определение «realtime»

Нужно разделять:

• Soft realtime — паузы предсказуемо короткие (единицы мс), редкие выбросы допустимы. Сюда метят ZGC и Shenandoah.
• Hard realtime — гарантированный worst-case bound на любую операцию выделения памяти. Пропуск дедлайна = провал системы. Вот тут начинается ад.

ZGC даёт паузы <1ms на практике, но это не hard realtime — это статистика, а не гарантия.

Технические сложности

Барьеры на чтение/запись. Чтобы делать GC конкурентно с мутатором, нужны read/write barriers — каждый доступ к ссылке проходит через дополнительный код. Это накладные расходы на каждое чтение поля объекта. ZGC использует load barriers + coloured pointers, Shenandoah — Brooks forwarding pointers. Реализовать барьеры так, чтобы они сами имели bounded worst-case time, нетривиально.

Аллокация должна быть bounded. new Object() в обычной JVM может триггернуть GC, расширение heap, syscall к ОС. Для hard realtime каждая аллокация должна укладываться в известный верхний предел. Решения: pre-allocated pools, region-based allocation, scoped memory (как в RTSJ — Real-Time Specification for Java).

Фрагментация. Если не компактить heap — фрагментация убьёт предсказуемость через час работы. Если компактить — нужно перемещать живые объекты конкурентно, обновлять все ссылки, и это тоже должно быть bounded. Metronome решает это incremental defragmentation с work-based scheduling.

Root scanning. Стеки всех потоков, JNI-ссылки, статические поля — всё это roots. Stop-the-world сканирование stacks даже на ZGC занимает время, пропорциональное количеству потоков. Полностью конкурентный root scan технически сложен.

JIT и deoptimization. HotSpot может деоптимизировать скомпилированный код в произвольный момент — это пауза, никак не связанная с GC, но ломающая realtime-гарантии. Нужен либо AOT (как у Azul Falcon или GraalVM Native Image), либо tiered компиляция с предсказуемыми переходами.

ОС и hardware. Page faults, TLB shootdowns, NUMA-эффекты, прерывания ядра, throttling CPU — всё это вносит jitter, который GC не контролирует. Для hard realtime нужен RTOS или PREEMPT_RT Linux с изоляцией ядер (isolcpus, nohz_full), pinning потоков, locked memory pages.

Финализаторы, weak references, class unloading. Каждая из этих штук — потенциальный источник непредсказуемых пауз. RTSJ их либо запрещает, либо строго ограничивает.

Почему это редко делают с нуля

Написать сам алгоритм GC — задача на полгода-год для опытного человека. Но GC в JVM — это не отдельный модуль, а глубокая интеграция с:

• интерпретатором (safepoints, OOP map)
• JIT (запись барьеров в скомпилированный код, deopt points)
• runtime’ом (object layout, card tables, remembered sets)
• threading (safepoint polling, parking)

В OpenJDK GC реализуется через HotSpot GC interface — это десятки тысяч строк кода-обвязки. Поэтому в реальности realtime-GC делают:

1. На базе существующей JVM с глубокими патчами (Azul, IBM J9 Metronome)
2. В специализированной JVM (JamaicaVM от Aicas — full hard realtime, сертифицирован для авиации)
3. Через RTSJ (JSR 1, JSR 282) — обход GC через ImmortalMemory/ScopedMemory

Что почитать

• David F. Bacon, «The Metronome: A Simpler Approach to Garbage Collection in Real-Time Systems» — классика, понятно объясняет work-based vs time-based scheduling
• Jones, Hosking, Moss, «The Garbage Collection Handbook» — глава про realtime GC
• RTSJ spec (JSR 282) — модель памяти для realtime Java
• Исходники ZGC и Shenandoah в OpenJDK — современный low-pause, не hard realtime, но многие идеи применимы