Я пытаюсь использовать JDK 13 JEP-350"Динамические CDS-архивы" с реальным (не академическим) приложением .
Для этого я добавил *Параметры 1006 *, -Xlog:class+load=debug и -Xlog:cds=debug JVM для сценария запуска моего приложения.Когда приложение завершает работу и HotSpot начинает создавать общий архив, журнал заполняется множеством предупреждений, таких как:
[215.210s][warning][cds] Skipping tech/toparvion/analog/remote/agent/si/ContainerTargetFile: Not linked
Но тот же класс в журнале загрузки классов не показывает ничего подозрительного:
[121.323s][info ][class,load] tech.toparvion.analog.remote.agent.si.ContainerTargetFile source: file:/E:/Issues/Temp/deploy-v0.12/lib/analog/lib/analog.slim.jar
[121.323s][debug][class,load] klass: 0x0000000801072ce0 super: 0x00000008002ea5e0 loader: [loader data: 0x000001dc2aba5eb0 for instance a 'jdk/internal/loader/ClassLoaders$AppClassLoader'{0x0000000702300000}] bytes: 1305 checksum: 1645a974
Существует 1824 таких пропущенных класса (как приложения, так и библиотеки) из 10566 классов, используемых приложением (включая сгенерированные ≈500).Я знаю, что далеко не все классы могут быть помещены в общий архив, но здесь я получаю ≈18% пропущенных классов, которые кажутся существенным недостатком эффективности CDS.
Итак, вопросы:
- Почему занятия пропускаются?
- Что я должен сделать, чтобы не пропускать и включать их в архив?
ОБНОВЛЕНИЕ
I 'Мы повторили тот же эксперимент со статическим архивом AppCDS, и он сработал, то есть класс ContainerTargetFile был успешно сохранен в общем архиве, а также в сотнях других классов.Таким образом, вышеупомянутая проблема, похоже, касается только Dynamic CDS Archives.