Как повторно преобразовать исполняющий метод с агентом JVMTI, который не имеет дальнейших вызовов?

Я инструментирую файл класса во время выполнения для различных целей. Для этого я использую агента JVMTI. Моя стратегия инструментирования метода заключается в вызове функции RetransformClasses для вызова функции ClassFileLoadHook. Эта стратегия отлично работает для всех методов, которые имеют любой дальнейший вызов после времени инструментирования, потому что фактическое инструментирование происходит при последующем вызове функции, но она не работает для любого метода, который не имеет дальнейших вызовов, таких как функция main в программе.

I хотите на лету проинструментировать метод во время его выполнения. Мне нужна какая-то процедура, например замена на стеке (OSR) инструментированного кода. Существует ли какая-либо стратегия в JVMTI или любой другой подход????

PS: Я открыт для редактирования / исправления исходного кода OpenJDK, если это может помочь.
1 9
jit jvm-hotspot

1 ответ:

После некоторых дальнейших размышлений я верю , что вы просите о чем-то, что может быть (может быть!) возможно технически; но требует больших усилий; но концептуально это не очень хороший подход.

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

Таким образом, вместо того, чтобы иметь реальное решение, я в основном имею список проблем:

    Прежде всего, если вы даже хотите изменить методы, которые уже были запущены и которые в настоящее время выполняются, вы говорите не только об инструментировании. То, что вы на самом деле хотите сделать, - это обеспечить свой собственный механизм "JIT", в то время как JVM JIT также существует и выполняет свою работу.
  • Итак, если вы действительно серьезно относитесь к этому; и хотите убедиться, что даже вещи в любом main() могут извлечь выгоду из ваших оптимизаций - тогда я думаю, концептуально, вы лучше проектируете и реализуете свой собственный JVM.
  • тогда мне интересно: вы говорите, что хотите охватить методы main(), которые уже запускают "длинные временные циклы". Это звучит так, как будто вы намерены исправить плохие проекты, бросив в него свои инструменты. Я думаю, что более здравый подход заключается в следующем: посмотрите на такие приложения иулучшите их дизайн.
  • в смысле: если "распараллеливание" произвольных приложений было бы "так просто" - это в любом случае, это будет частью СП. И тот факт, что это не так; и то, что JVM не делает такого рода оптимизаций, имеет хорошую причину: вероятно, очень трудно получить это правильное и надежное.
Другими словами: Япредполагаю, что у вас есть проблема XY; и проблема X заключается в том, что приложение(ы), с которым вы имеете дело, может извлечь выгоду из "распараллеливания". Но это то, что очень трудно сделать "вообще".

В этом смысле; я бы скорее определил какой-то вид архитектуры (это может включать в себя конкретные, четко определенные шаги, как приложение должно "запускаться"; так что ваши инструменты могут успешно выполнять свою работу) и получить опыт с этим подходом в первую очередь. Смысл: скажите своим родителям, чтобы они не помещали "длинные циклы" в свои main() в первую очередь (как уже было сказано; это само по себе звучит как довольно плохой дизайн для меня!).

2