Hi, we observe a very strange problem in the JUnitTestRunner: It runs out of memory with the default settings, with the following stack trace:
[junit] [Unloading class sun.reflect.GeneratedConstructorAccessor2]
[junit] [Unloading class sun.reflect.GeneratedConstructorAccessor3]
[junit] [Unloading class sun.reflect.GeneratedConstructorAccessor1]
[junit] Exception in thread "main" java.lang.OutOfMemoryError: Java heap
space
[junit] at java.lang.StringCoding
$StringDecoder.decode(StringCoding.java:133)
[junit] at java.lang.StringCoding.decode(StringCoding.java:173)
[junit] at java.lang.StringCoding.decode(StringCoding.java:185)
[junit] at java.lang.String.<init>(String.java:571)
[junit] at java.lang.String.<init>(String.java:594)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:449)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:766)
When this happens, JUnitTestRunner is running:
if (startTestSuiteSuccess) {
sendOutAndErr(new String(outStrm.toByteArray()),
new String(errStrm.toByteArray()));
}
The outStrm has captured roughly 23M of data at the moment, which will
be copied first for ByteArrayOutputStream.toByteArray(), and then in
String.<init> -> StringDecoder.decode() again.
So at the end, we have 3 times these 23M lying around, blowing away or
VM.
An immediate improvement would be to use outStrm.toString() directly,
which would copy the buffer only once.
I can open a bug report in the issue tracker, but what would you need as
data points there?
Regards,
--
Andreas
signature.asc
Description: This is a digitally signed message part
