Add thread-per-test-class execution model #3941
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
snazy
force-pushed
the
thread-per-test-class
branch
2 times, most recently
from
d466d4c
to
784cfc2
Compare
The thread-per-test-class execution model runs tests via one thread per test class. This model is primarily useful in situations when test executions attach `ThreadLocal`s to the test worker thread, which "leak" into other test class executions. This problem can lead to out-of-memory errors, if the `ThreadLocal`s reference (large) object trees, either as its value or via its initial-value `Supplier`, which cannot be cleaned up / garbage collected, because the `ThreadLocal` is referenced by the test worker thread. The problem becomes even worse, if the test class creates its own class loader and attaches `ThreadLocal`s that reference classes loaded by such class loaders. In such cases the whole class loader including all its loaded classes and (static) state is not eligible for garbage collection, leaking more heap (and non-heap) memory. Using one thread per test class works around the above problem(s), because once the (ephemeral) thread per test-class finishes, the whole thread and all its `ThreadLocal`s become eligible for garbage collection. Particularly Quarkus unit tests (`@QuarkusTest` annotated test classes) benefit from this execution model. This change cannot eliminate other sources of similar leaks, like threads spawned from tests or not removed MBeans. Those kinds of leaks are better handled by the test code or the tested code providing "proper" cleanup mechanisms. This new execution is implemented via the introduced `ThreadPerClassHierarchicalTestExecutorService`, a 3rd model in addition to `SameThreadHierarchicalTestExecutorService` and `ForkJoinPoolHierarchicalTestExecutorService`. It is enabled if `junit.jupiter.execution.threadperclass.enabled` is set to `true` and `junit.jupiter.execution.parallel.enabled` is `false`. Issue: junit-team#3939
snazy
force-pushed
the
thread-per-test-class
branch
from
784cfc2
to
f42e100
Compare
|
|
|
/cc @sormuras |
mpkorstanje
reviewed
Sep 9, 2024
|
|
||
| UniqueId.Segment lastSegment = testDescriptor.getUniqueId().getLastSegment(); | ||
|
|
||
| if ("class".equals(lastSegment.getType())) { |
There was a problem hiding this comment.
This is an implementation detail of the JUnit Jupiter Engine so it should not be used in the platform module which is test engine agnostic. Perhaps you can use TestDescriptor.getSource instead to potentially obtain the class source?
Note: I'm not part of the JUnit Team, just commenting.
marcphilipp
reviewed
Sep 18, 2024
There was a problem hiding this comment.
Thanks for the PR! I'm not convinced whether it's addressing the problem on the right level, though. An alternative would be for Jupiter to provide a new ClassExecutionInterceptor extension point (or a new method in InvocationInterceptor) that would be called from ClassTestDescriptor.around. I'll bring this up for discussion with the team.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The thread-per-test-class execution model runs tests via one thread per test class. This model is primarily useful in situations when test executions attach
ThreadLocals to the test worker thread, which "leak" into other test class executions. This problem can lead to out-of-memory errors, if theThreadLocals reference (large) object trees, either as its value or via its initial-valueSupplier, which cannot be cleaned up / garbage collected, because theThreadLocalis referenced by the test worker thread.The problem becomes even worse, if the test class creates its own class loader and attaches
ThreadLocals that reference classes loaded by such class loaders. In such cases the whole class loader including all its loaded classes and (static) state is not eligible for garbage collection, leaking more heap (and non-heap) memory.Using one thread per test class works around the above problem(s), because once the (ephemeral) thread per test-class finishes, the whole thread and all its
ThreadLocals become eligible for garbage collection.Particularly Quarkus unit tests (
@QuarkusTestannotated test classes) benefit from this execution model.This change cannot eliminate other sources of similar leaks, like threads spawned from tests or not removed MBeans. Those kinds of leaks are better handled by the test code or the tested code providing "proper" cleanup mechanisms.
This new execution is implemented via the introduced
ThreadPerClassHierarchicalTestExecutorService, a 3rd model in addition toSameThreadHierarchicalTestExecutorServiceandForkJoinPoolHierarchicalTestExecutorService. It is enabled ifjunit.jupiter.execution.threadperclass.enabledis set totrueandjunit.jupiter.execution.parallel.enabledisfalse.Resolves #3939.
Overview
I hereby agree to the terms of the JUnit Contributor License Agreement.
Definition of Done
@APIannotations