LocationImpl adds performance overheads due to instantiating a stack trace

[j-baker]

I'm trying to use Mockito in a test of a Java class I didn't write. It takes a dependency which I am stubbing out using Mockito. Skipping all of the business logic, the code ends up being rather similar to this:

SomeClass mocked = mock(SomeClass.class, Mockito.withSettings().stubOnly());
when(mocked.someParam()).thenReturn(0);

for (int i = 0; i < bigNumber; i++) {
    mocked.someParam();
}

This is in Mockito 4.6.1. This is extremely slow, and looking at Mockito this seems to be a problem for two reasons.

Firstly, when a mock invocation occurs, LocationImpl is instantiated. This instantiates a Throwable, which constructs a stack trace, error message, etc (which is then discarded). In my test, Mockito was generating 70k exceptions per second.

The second slowdown that seemed to be affecting me comes from TypeSafeMatching.getArgumentType. This iterates through all of the methods on the argument matcher class to find the appropriate matches method, seemingly also for each method call. By performing this operation, a lot of JVM internal datastructures get copied - it calls Class.getMethods, which copies all the methods on the class. This method could probably be cached on a per-class basis.

This dramatically affected my application's allocation rate; Mockito was leading to approx 3.4GiB/sec allocations. In the end, I rewrote my mock using ByteBuddy proxies directly. It took the test runtime from 30 seconds down to 1, with the number of exceptions being created per second going down from 70k to ~0.

I know that Mockito isn't meant to be a Netty-like high performance library, but wanted to flag these two codepaths as affecting every mock call.

[TimvdLippe]

mockito/src/main/java/org/mockito/internal/exceptions/stacktrace/StackTraceFilter.java

Line 75 in 95b43e5

public StackTraceElement filterFirst(Throwable target, boolean isInline) {

is supposed to make this fast if the JVM supports it, but I am not sure if that still works. #2225 was supposed to fix it, but I had to abandon it.

Maybe you can use these to fix the performance problems?

[j-baker]

Yes, the method currently used relies on JavaLangAccess containing a getStackTraceElement method. The diff that integrated the StackWalker api deleted this and so this regression has existed since Java 9.

openjdk/jdk@eb2c6c5#diff-9908a97582edc388983be46caac4de91a4b958df46d86b9bd739f577a55c01b0L105