indy instrumentation - leftovers migration #13074
Conversation
…nstrumentation into indy-leftovers
| @@ -28,8 +32,17 @@ public boolean defaultEnabled(ConfigProperties config) { | |||
| } | |||
|
|
|||
| @Override | |||
| public boolean isIndyModule() { | |||
| return false; | |||
| public void injectClasses(ClassInjector injector) { | |||
There was a problem hiding this comment.
I don't think having any invokedynamic-based instrumentation/proxies is a good idea for the lambda instrumentation: The reason is that we unecessarily risk recursions for the invokedynamic bootstrapping if lambdas are used in there in some unfortunate places, even if this is not the case right now.
I feel we should rather simply move those two classes to the agent bootstrap package, lambda instrumentation imo is special enough to justify this. Alternatively, we could directly inject the classes via injectedClassNames().
There was a problem hiding this comment.
Good point, until moving those to the bootstrap package is further discussed I've switched to using injectedClassNames() in 45ead47
| try { | ||
| byte[] result = | ||
| transformer.transform( | ||
| targetClass.getClassLoader(), slashClassName, targetClass, null, classBytes); |
There was a problem hiding this comment.
[for reviewer] here we used to call .transform(...) with null target class.
However, the implementation of JavaModuleClassFileTransformer needs targetClass to be set in order to get the jpms module, in practice it does not seem to make any difference as the transformation should be idempotent and identical when defining or redefining the class. Also here the targetClass is never null thanks to the call to isHelperClass above.
| } | ||
|
|
||
| @Override | ||
| public byte[] transform( |
There was a problem hiding this comment.
[for reviewer] here we override the pre-java9 API and then resolve the class module from the class, this allows to transparently call it from code compiled with Java 8 API level.
In practice, there is only a single usage for this in the internal lambda instrumentation, which makes it equivalent to the (now removed) Java9LambdaTransformer.
| instrumentationInstalled = true; | ||
| ClassFileTransformerHolder.setClassFileTransformer(resettableClassFileTransformer); | ||
| if (JavaModule.isSupported()) { | ||
| // wrapping in a JPMS compliant implementation |
There was a problem hiding this comment.
[for reviewer] wrapping at registration time helps to make the consumer transparently use it with java 8 API.
| public class InlineIbmResourceLevelInstrumentationModule extends InstrumentationModule { | ||
| public InlineIbmResourceLevelInstrumentationModule() { | ||
| super("inline-ibm-resource-level"); | ||
| public class IbmResourceLevelInstrumentationModule extends InstrumentationModule { |
There was a problem hiding this comment.
[for reviewer] there is no need to maintain an inline and indy variants of this instrumentation, so we only need one that is compatible with both.
Should be the final step of #11457, hopefully completing it.
There are currently 5 overrides of
isIndyModule()and the goal here is to removeallmost of them, hence allowing to move forward with the next steps described in #13031This PR should be considered a "work in progress" until all the checks are passing before being ready for review.