Execution fails with "Retried waiting for GCLocker too often allocating"

[mgroth0]

When testing my module, it fails with errors like:

[4.776s][warning][gc,alloc] ClassGraph-worker-15: Retried waiting for GCLocker too often allocating 1026 words

This occurs for a module which does not define any Kottest tests. Simply adding kotest as a test dependency causes this error, and removing it as a dependency prevents the error.

This does not occur on all of my modules. I suspect it is only happen on those with a larger amount of items on the classpath.

Kotest version: 5.8.0
Gradle version: 8.6
Gradle-JVM version: temurin-20.0.2

[mgroth0]

Here is someone who had the same issue: https://slack-chats.kotlinlang.org/t/9020969/i-ve-started-getting-with-the-last-couple-5-5-4-and-5-5-5-ve

[mgroth0]

I just discovered a workaround:

tasks.withType<Test>().configureEach {
    systemProperty("kotest.framework.classpath.scanning.config.disable","true")
    systemProperty("kotest.framework.classpath.scanning.autoscan.disable","true")
}

This prevents the error.

[mgroth0]

My recommendation is that as an essential fix, Kotest should find a way to catch this exception and report a more informative error message to the user. Otherwise, the error message that is currently printed will confuse many people.

This will be a breaking change, but for future versions I suggest making classpath scanning features opt-in. If they are causing OOM-like errors, they must have a large performance cost. And from what I just read on the docs, the features they support are not essential for running basic tests. I think autoscanning is a great feature but it should just be opt-in. Users who do not get the error message I am getting here might incur performance costs that they do not realize, and their tests will run slower for reasons they do not understand.

[mgroth0]

https://kotest.io/docs/framework/project-config.html
https://kotest.io/docs/next/framework/extensions/extensions-introduction.html

[sksamuel]

My recommendation is that as an essential fix, Kotest should find a way to catch this exception and report a more informative error message to the user. Otherwise, the error message that is currently printed will confuse many people.

This will be a breaking change, but for future versions I suggest making classpath scanning features opt-in. If they are causing OOM-like errors, they must have a large performance cost. And from what I just read on the docs, the features they support are not essential for running basic tests. I think autoscanning is a great feature but it should just be opt-in. Users who do not get the error message I am getting here might incur performance costs that they do not realize, and their tests will run slower for reasons they do not understand.

In 6.0, classpath scanning will be disabled by default.

[mgroth0]

Hey @sksamuel, thank you for the update.

Just to confirm, will both of these be disabled by default in 6.0?

• kotest.framework.classpath.scanning.config.disable
• kotest.framework.classpath.scanning.autoscan.disable

[smocherla-brex]

I did want to echo as well that in large repositories/projects, kotest ends up using a enormous amount of heap memory and it's a huge bottleneck in having test parallelism. Until we actually did heap dump analysis, it wasn't clear and we found out it was happening because of classgraph scanning of the whole classpath. It's possible other folks might run into it and it's not quite easy to find out - for existing 5.x versions it'd be good to highlight in the docs that the defaults can have a huge performance impact (memory wise).

Disabling this reduces our test heap usage quite a bit from 4B to ~1Gb, but even that seems large. It seems like classgraph is still used for loading some JAR files in memory, which results in OutofMemory errors. Is there a way to disable this so that we can reduce the memory usage further?