[
https://issues.apache.org/jira/browse/SUREFIRE-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522446#comment-17522446
]
Tibor Digana edited comment on SUREFIRE-2072 at 4/14/22 6:15 PM:
-----------------------------------------------------------------
[~mickael.istria]
We can make the cache much smaller, e.g. 1024 bytes, but I think the real
problem is that we do not have a proper clean up of {{stdout}} and {{stderr}}
in {{TestSetRunListener.detailsForThis}} after the particular test class has
finished. Anyway, this class and {{StatelessXmlReporter}} will be reworked. We
have several problems with them.
The reason why it is 64KB:
Suppose you have {{forkMode=pertest}} and {{reuseForks=false}}. Each test class
runs in a separate fork.
The object of {{TestSetRunListener}} is not in fork. It is in Maven process.
You have 1000 test classes, each has one test method.
Suppose you have a super small project and each fork eats 10MB of native memory.
Altogether, all the forks would eat 1000 x 10MB = 10GB.
Let's count the additive memory consumption in the Maven process.
You have 1000 test classes and one cache, this means the object
{{TestSetRunListener}} would eat 1000 x 64KB = 64MB.
So the penalty is not on the side of the cache.
The effectivity of memory clean up is the issue, I would say.
was (Author: tibor17):
[~mickael.istria]
We can make the cache much smaller, e.g. 1024 bytes, but I think we do not have
a proper clean up of {{stdout}} and {{stderr}} in
{{TestSetRunListener.detailsForThis}} after the particular test class has
finished. Anyway, this class and {{StatelessXmlReporter}} will be reworked. We
have several problems with them.
The reason why it is 64KB:
Suppose you have {{forkMode=pertest}} and {{reuseForks=false}}. Each test class
runs in a separate fork.
The object of {{TestSetRunListener}} is not in fork. It is in Maven process.
You have 1000 test classes, each has one test method.
Suppose you have a super small project and each fork eats 10MB of native memory.
Altogether, all the forks would eat 1000 x 10MB = 10GB.
Let's count the additive memory consumption in the Maven process.
You have 1000 test classes and one cache, this means the object
{{TestSetRunListener}} would eat 1000 x 64KB = 64MB.
So the penalty is not on the side of the cache.
The effectivity of memory clean up is the issue, I would say.
> Surefire retains too much heap in some case, leading to OutOfMemory
> -------------------------------------------------------------------
>
> Key: SUREFIRE-2072
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2072
> Project: Maven Surefire
> Issue Type: Bug
> Reporter: Mickael Istria
> Priority: Major
>
> Most likely since SuREFIRE-1845, every test execution can retain 64kB of RAM
> (as cache). Which caching is welcome, this cannot scale with some big test
> suites of several thousands of tests and cause OutOfMemoryError.
> This is the case when running Eclipse JDT dom test suite, since
> tycho-surefire-plugin started to adopt surefire 3.0.0.M6, as described in
> https://github.com/eclipse/tycho/issues/879#issuecomment-1096454637
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
