Создание пользовательской JVM с большим заголовком объекта

Question

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

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

Что я хотел бы знать, так это то, что эксперты JVM здесь думают о возможности создания пользовательской виртуальной машины с большим заголовком объекта (например, на 8 байт больше). markOop.hpp довольно неплохо объясняет содержание слова-метки для различных существующих разновидностей (32 бита, 64 бита, 64 бита со сжатыми ой), и мне было интересно, как трудно будет расширить заголовок, чтобы я мог добавить немного дополнительного информация об объектах (без пометки нет, см. мой пост здесь ).

Так что, прежде чем углубляться в это, я надеялся, что кто-то, имеющий опыт в этом, может дать некоторую раннюю обратную связь. Например, это «самоубийственная миссия», потому что во всем мире слишком много мест, где существуют жестко закодированные предположения относительно размера заголовка и смещений? Или все это довольно централизовано и может быть выполнено с разумными усилиями, не рискуя все сломать? Любой указатель на то, что может нуждаться в особом уходе и какие последствия это может иметь (помимо очень очевидного; больше потребления памяти)?

Answer 1

Определенно можно увеличить заголовок объекта (я уже видел такие эксперименты ранее), хотя это будет не так просто, как просто добавить новое поле в класс oopDesc ​​. Я считаю, что в коде JVM есть несколько мест, которые зависят от размера заголовка объекта, но их не должно быть слишком много. Размер заголовка объекта уже различается в зависимости от платформы и параметра UseCompressedOops, поэтому большинство мест в коде уже используют относительные смещения и не будут страдать от нового поля.

Другой вариант заключается не в расширении заголовка, а в добавлении нового ложного поля в класс java.lang.Object. HotSpot уже имеет механизм для добавления таких полей, ищите InjectedField в источниках. Однако это тоже не будет тривиальным. Существуют некоторые жестко заданные смещения для системных классов, см. JavaClasses :: check_offsets . Это тоже нужно исправить.

Оба подхода примерно одинаковы с точки зрения усилий по внедрению. В обоих случаях я предлагаю начать с debug (не fastdebug) сборок JVM, поскольку они включают в себя множество полезных утверждений, которые рано уловят возможные проблемы смещения.

Услышав о вашем проекте, я думаю, что у вас также есть третий вариант: отказаться от требования «только JVMTI» и переписать некоторые части агента в Java, используя мощь инструментария байт-кода и компиляции JIT. Да, это может немного изменить выполняемый Java-код и, вероятно, привести к загрузке большего количества классов, но действительно ли это имеет значение, если с точки зрения пользователя влияние будет даже меньше, чем с агентом только для JVMTI? Я имею в виду, что влияние на производительность может быть значительно меньше, если нет собственных переключателей Java <->, издержек JVMTI и так далее. Если у агента низкие накладные расходы и он работает со стандартной JVM, я думаю, это не большая проблема - включить его в производство, чтобы получить его интересные функции, не так ли?