Force inlining of classloading instrumentations to prevent indy recursions #13282
Conversation
…g-fix # Conflicts: # .github/workflows/build-daily-no-build-cache.yml # .github/workflows/build-daily.yml # .github/workflows/reusable-test-indy.yml
JonasKunz
added
the
test openj9
|
@trask this seems to be successful in fixing the underlying issue. The test failures just come from the fact that a new variable (indy) was added to the GH-actions matrix which isn't accounted for in the rest of the workflow. Do you want to move ahead with this addition to the test matrix or was it just an experiment? |
ya, I think it would be good to add this to our regular automated testing, as part of moving it towards the default mechanism |
…g-fix # Conflicts: # .github/workflows/reusable-test-indy.yml
| public List<String> injectedClassNames() { | ||
| return getAdditionalHelperClassNames(); |
There was a problem hiding this comment.
In this case, do the classes are injected in the target CL or is it only their proxies that happen to have the same name ?
There was a problem hiding this comment.
We don't want to use proxies here, because then we'd go through the same invokedynamic recursions again. Therefore the classes are directly injected.
Attempts to fix the problems uncovered by #13095. Also includes the changes from this PR to always run the full test matrix with indy.
OpenJ9 makes things hard for invokedynamic instrumentation in combination with our classloader instrumentations.
The problem is that in OpenJ9 the bootstrapclassloader is implemented in java and also calls / uses
Classloader.loadClassfrom its superclass. Even if we prevent recursions from happening in the bootstrapping, the problem still remains: After the bootstrap method returns, the JDK will still execute some code to finalize the invokedynamic binding, which again involves classloading from the bootstrap classloader.This PR forces classloader.loadClass instrumentations to be inlined, but without relying on the inlining-infrastructure we want to eventually remove. Instead it uses the
TypeTransformer.applyTransformerescape hatch also used by the lambda instrumentation.