Crash when using a custom classloader to load instrumentable code

[mikehearn]

Our app loads classes dynamically inside a simple ClassLoader (it just loads class files from somewhere that isn't disk). This causes instrumentation failures for code that works fine if loaded non-dynamically.

From looking at the code it appears that there is some support for differing classloaders but it's not clear how it's meant to work. The Java agent creates a single instrumentor, with the default app class loader, and then that's always used to look up classes. The classloader passed into the transform method is added to a global weak set, but it's unclear why or where that set is used. When methods are loaded for instrumentation, the MethodDatabase in the instrumentor is used, and that uses the classloader from startup time.

Is the support for multiple classloaders unfinished? What is the purpose of the Retransform class, as it seems there are some mechanisms there to work with classloaders but IntelliJ claims these methods aren't used anywhere.

[pron]

The instrumentor definitely should (i.e, in terms of specification) support multiple class loaders, but our current test suite doesn't test this, and I assume this use-case hadn't been exercised prior to you, to I'm going to mark this as a bug, and take a look at it soon.

[mikehearn]

Thanks!

[circlespainter]

@mikehearn As highlighted by #209, at present classes with the same name but different classloaders clash in Quasar's suspendables table. I've been able to exploit this clash to create a situation where two classes with the same name, but loaded by different classloaders, annotate the same method as @Suspendable and not suspendable resp. but it gets instrumented in both cases.

I haven't yet figured out how to make the other way around happen though: it looks to me like such clashes can only increase the "suspendable level" of methods, not decrease it. Did this happen to you instead? Or which other problematic situations have you found?

[mnesbit]

When the JavaAgent is passed a class loaded in a custom class loader then the MethodDatabase will only call getResources on the application ClassLoader. As a result the referenced parent classes and Suspendable interfaces cannot be found if they are only reachable by the custom ClassLoader. The default behaviour is to assume the method call are suspendable and carry on. Whilst this does work it means there are lots of warnings from quasar about missing classes and presumably the unecessary instrumentation will have a performance impact.