JEP draft: refactor per-instance metadata to be separate from ClassInfo metadata

Сейчас у InstanceKlass три обязанности одновременно:

1. Он хранит содержимое загруженного class-файла и состояния разрешения.
2. Он представляет «живой тип» (подтип Klass) в служебном учёте JVM.
3. Он служит указателем в заголовке экземпляра объекта, размещённого в куче.

Каждая из этих обязанностей усложняет InstanceKlass. Давайте разделим его на два или три модуля:

1. ClassFile (или ClassFileInfo, ClassFileStructuure и т. д.) должен быть загруженным class-файлом со связанным ConstantPool, в котором хранятся константы и состояния их разрешения. Бо́льшую часть того, что сейчас содержится в InstanceKlass, следует перенести в этот новый класс, переименовав.

2. InstanceKlass должен стать абстрактным API с одной реализацией под названием ClassFileKlass, которая содержит указатель на ClassFile. Эти типы нужно «выпотрошить» и оставить в них только методы, которые непосредственно относятся к служебному учёту типов в JVM. Сюда входят методы, общие с Klass, arrayKlass и т. д.

3. Заголовок объекта может содержать прямой указатель на InstanceKlass, как и сейчас. При сжатии (или при других приёмах в будущем) его можно кодировать и декодировать.

Когда мы начнём реализовывать специализацию, возникнет различие между тремя вещами:

1. Обычный класс.
2. Параметрический класс (то, что мы раньше называли «шаблонным классом»)
3. Species параметрического класса.

Очевидно, случаи 1 и 2 находятся в прямом взаимно однозначном соответствии со структурой ClassFile, а случай 3 — нет. Вместо этого случай 3 связан со случаем 2 отношением «многие к одному». Отсюда напрашиваются следующие типы:

0. InstanceKlass — абстрактный (мы с самого начала хотели это сделать)
1. ClassFileKlass <: InstanceKlass (сегодняшний код, переименованный)
2. в ClassInfo добавлено всё параметрическое хозяйство
3. SpeciesKlass <: InstanceKlass указывает на ClassInfo и на всё, что касается привязки параметров

То, что касается привязки параметров, должно включать состояния пула констант для параметрических констант: они связаны с исходными ClassFile и ConstantPool отношением «многие к одному». Для этого нам понадобится отдельный тип, работающий под предлагаемым зеркалом java.lang.invoke.ParameterBinding.

Сейчас Method знает, к чему он относится, потому что у него есть указатель на пул констант, который находится во взаимно однозначном соответствии с информацией ClassFile вокруг метода, — всё очень уютно. Для специализированных методов такое устройство можно сохранить, поскольку привязка параметров при вызове специализированного метода связана с кадром стека, а не с самим методом.

См. также: http://mail.openjdk.java.net/pipermail/valhalla-dev/2020-October/008083.html