Agent throws NoClassDefFoundError if attached via Gradle test JVM args

[dreis2211]

Hi 👋

I wanted to try the goodness of this new agent in one of my test-suites and was so far unable to get it running. For easier repro I created a small project under https://github.com/dreis2211/type-pollution-agent-test where you only need to adjust the path of the agent here and run ./gradlew test.
When I do this on my local macbook I always get the following:

java.lang.NoClassDefFoundError: io/type/pollution/agent/TraceInstanceOf
        at org.slf4j.LoggerFactory.findPossibleStaticLoggerBinderPathSet(LoggerFactory.java:311)
        at org.slf4j.LoggerFactory.bind(LoggerFactory.java:146)
        at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
        at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:417)
        at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:362)
        at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:388)
        at org.gradle.internal.concurrent.CompositeStoppable.<clinit>(CompositeStoppable.java:37)
        at org.gradle.internal.service.DefaultServiceRegistry$OwnServices.<init>(DefaultServiceRegistry.java:391)
        at org.gradle.internal.service.DefaultServiceRegistry.<init>(DefaultServiceRegistry.java:107)
        at org.gradle.internal.service.DefaultServiceRegistry.<init>(DefaultServiceRegistry.java:94)
        at org.gradle.internal.logging.services.LoggingServiceRegistry.<init>(LoggingServiceRegistry.java:47)
        at org.gradle.internal.logging.services.LoggingServiceRegistry$CommandLineLogging.<init>(LoggingServiceRegistry.java:157)
        at org.gradle.internal.logging.services.LoggingServiceRegistry$CommandLineLogging.<init>(LoggingServiceRegistry.java:157)
        at org.gradle.internal.logging.services.LoggingServiceRegistry.newEmbeddableLogging(LoggingServiceRegistry.java:101)
        at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:90)
        at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:71)
        at worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:69)
        at worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:74)
Caused by: java.lang.ClassNotFoundException: io.type.pollution.agent.TraceInstanceOf
        at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
        ... 18 more

I haven't really looked deep into the agent code yet, but maybe you can see something that would enable the agent to run in these kind of scenarios. Maybe it's even something obvious that I overlooked, in any case I'd appreciate some help.

Cheers,
Christoph

[franz1981]

It looks like the jar of the agent not being in the application classpath or... don't know :)
I will likely take a look after Monday next week, but I see you have opened spring-projects/spring-boot#32916: did you find anything interesting/it has worked for you there?

[dreis2211]

Well, I can still run it on fat-jars with java -jar ... but that's not how e.g. Gradle tests are run. Since agent classes are loaded by the system classloader if I remember correctly, it's probably some sort of problem with that. In the particular issue you mentioned I just created a tiny Spring-Boot app (a JAR) to test with.

So far not more than (interesting) noise - no real performance problems. Quite a big portion in Bytebuddy, but in a timeframe/environment where no real concurrent access is happening and thus the problem with the secondary super cache won't really occur. And a lot of cases where the interfaces are not using any multi-inheritance (which I also believe is somewhat a prerequisite) and thus seem most likely false-positives. At least the changes I did here and there didn't show any gains in local benchmarks. They just get rid of potential future issues and reduce some noise ;)

Good luck for the podcast on Monday. Eager to find out more...

[franz1981]

At least the changes I did here and there didn't show any gains in local benchmarks. They just get rid of potential future issues and reduce some noise ;)

Exactly, but beware a thing key to trigger the issue, arming what seems false positives: it happens when more then one concrete type hit the type check bytecode (sometime inlining help to keep the type profile "monomorphic" making related type check constant folded no-op) for "enough" times.
You can see it on a Netty benchmark where the first "breed" of such issue has been spotted: netty/netty#12708 ;check the microbench I have modified on the related pr, that introduce the "type pollution" at the call-site/type-check bytecode.
In short: local benchmark often lack variety (for good reasons, given that try to keep cases isolated!) and, moreover, given they run on consumer CPU doesn't have the same cost by accessing remote caches (more on this on the insight), meaning that real world scenario on server machines are sadly the best place where you can observe such issue.
And this is not the scary part yet, really: will explain something more on Monday ;)