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

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

Я хочу применить метод "на лету" во время его выполнения. Я хочу, чтобы какая-то процедура, например, замена на стеке (OSR) инструментального кода. Есть ли какая-либо стратегия, доступная в JVMTI или любом другом подходе?

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

Ответ 1

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

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

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

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

Другими словами: я думаю, у вас есть проблема XY; и проблема X заключается в том, что приложение (ы), с которым вы имеете дело, может извлечь выгоду из "распараллеливания". Но это очень сложно сделать "вообще".

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