如何用没有进一步调用的JVMTI代理重新转换执行方法? [英] How to retransform an executing method with JVMTI agent which has no further invocations?

问题描述

我正在出于各种目的在运行时检测类文件.为此，我正在使用JVMTI代理.我对一种方法进行检测的策略是调用RetransformClasses函数来调用ClassFileLoadHook.此策略适用于在插装后进行任何进一步调用的所有方法，因为实际的插装发生在随后的函数调用中，但不适用于任何在程序中没有诸如main函数之类的进一步调用的方法.

I am instrumenting a class file during runtime for various purposes. I'm using a JVMTI agent to that end. My strategy to instrument a method is to call RetransformClasses function to invoke ClassFileLoadHook. This strategy works fine for all the methods which have any further invocation after the time of instrumentation because actual instrumentation happens at subsequent function call, but it doesn't work for any method which does not have further invocations like main function in a program.

我想在执行过程中动态地检测一个方法.我需要一些过程，例如已检测代码的堆栈上替换(OSR).

I want to instrument a method on the fly during its execution. I want some procedure like On-Stack Replacement (OSR) of the instrumented code. Is there any strategy available in JVMTI or any other approach????

PS:如果可以，我愿意编辑/修补OpenJDK源代码.

PS: I'm open to editing/patching OpenJDK source code if that can help.

推荐答案

经过进一步思考，我相信，您正在寻求一些在技术上可能(也许！)的东西；但需要很多努力；但是从概念上来说，这不是一个好方法.

After some further thinking, I believe you are ask for something that might maybe (maybe!) be possible technically; but require lots of efforts; but conceptually it is not a good approach.

我假设，您的要求实际上是您想要检测扔给您的任何类型的应用程序，以通过在后台并行化"来提高其性能.

I assume your requirement is actually that you want to instrument any kind of application thrown at you in order to improve its performance by doing "under the cover parallelizing".

因此，我没有一个真正的解决方案，而是主要关注的问题列表:

So, instead of having a real solution, I mainly have a list of concerns:

• 首先，如果您甚至想修改已经触发且当前已执行的方法，那么您不仅在谈论检测.您真正想做的是提供自己的"JIT"机制-JVM JIT也在那里，并完成其工作.
• 因此，如果您对此真的很认真；并且要确保即使任何main()中的内容都可以从您的优化中受益-然后，从概念上讲，我认为您最好设计并实现自己的 JVM.
• 那我想知道:您说要介绍已经在运行长时间循环"的main()方法.听起来您打算通过扔出仪器来修复不良设计.我认为更合理的方法是:研究此类应用程序，并改进其设计.
• 从某种意义上说:如果并行化"任意应用程序将那么容易"-无论如何它将是JVM的一部分.而且事实并非如此；而且JVM不进行这种优化是有充分的理由的:要获得正确和强大的功能，可能非常困难.

• First of all, if you even want to modify methods that were already triggered and that are currently executed, you are not only talking about instrumenting. What you actually want to do is to provide your own "JIT" mechanism - while the JVM JIT is also there, and doing its job.
• So, if you are really serious about this; and want to make sure that even the things in any main() can benefit from your optimizations - then I think, conceptually, you are better of designing and implementing your own JVM then.
• Then I am wondering: you say want to cover main() methods that are already running "long time loops". That sounds like you intend to fix bad designs by throwing your instrumentation at it. I think the more sane approach is: look into such applications, and improve their design.
• In the sense of: if "parallelizing" arbitrary applications would be "that easy" - it would be part of the JVM anyway. And the fact that it is not; and that the JVM doesn't do such kind of optimizations is for a good reason: it is probably super hard to get that correct and robust.

换句话说:我猜您有一个XY问题； X问题是您正在处理的应用程序可以从并行化"中受益.但这是总体上"很难做到的.

In other words: I guess you have an XY problem; and the X problem is that the application(s) you are dealing could benefit from "parallelizing". But that is something that is very hard to do "in general".

从这个意义上说；我宁愿定义某种体系结构(其中可能包括应用程序应如何启动"的明确的明确步骤；以便您的仪器能够成功完成其工作)，并首先获得使用该方法的经验.含义:告诉您的人们首先不要在他们的main()中放入长时间运行的循环"(如上所述；这对我来说听起来很糟糕！).

In that sense; I would rather define some kind of architecture (that might include specific, well-defined steps how an application should "start up"; so that your instrumentation can do its work successfully) and gain experience with that approach first. Meaning: tell your folks to not put "long running loops" into their main() in the first place (as said; that alone sounds like pretty bad design to me!).

这篇关于如何用没有进一步调用的JVMTI代理重新转换执行方法?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！