[jbossts-issues] [JBoss JIRA] Commented: (JBTM-555) make memory leak tests more robust
[
https://jira.jboss.org/jira/browse/JBTM-555?page=com.atlassian.jira.plugi...
]
Romain PELISSE commented on JBTM-555:
-------------------------------------
Maybe running the test with the gc.log and analysing it afterwards would also be a sounded
approach ?
Basically what is to know of the test is : "Is there memory consumption below a
certain threshold ?", this could be answer by a gc.log file... (However, this is
rather tied to the Sun JVM implementation).
Moreover, analysing the GC log also allow to see how the memory consumtion progress, maybe
spotting a memory consumption rising (even if it's stay beneath the appropriate
threshold during the test) that wasn't rising in the previous version.
That gain this sort of knowledge would requires you to either run test on previous tag
release or keep previous GC.log on file, however doing the first one with Git is not
really that complicated (in fact, it will be similar to using the 'bissect'
command).
On other "trick" that I know of is the Ant's for-each statement in the
ant-contrib.jar, which will allow to do something like this:
<for-each ..>
<junit .... > <!-- run one particular test or test group -->
<!-- Load memory configuration for an appropriate test from a properties
file -->
<property name="${testId}-config.."/>
<jvmarg value="-Xms${memory.start}"/>
<jvmarg value="-Xmx${memory.max}"/> <!--
...
Hope that's help.
make memory leak tests more robust
----------------------------------
Key: JBTM-555
URL: https://jira.jboss.org/jira/browse/JBTM-555
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Testing, Transaction Core
Affects Versions: 4.6.1
Reporter: Jonathan Halliday
Assignee: Jonathan Halliday
Fix For: future
Some tests in the txcore group attempt to detect memory leaks by
setup
System.gc()
take memory reading
doTransactionStuff
System.gc()
take another memory reading
This is unreliable, as System.gc() is only advisory to the runtime. There is no way to
FORCE gc from within the jvm. This causes the tests to be somewhat unreliable.
Dirty tricks to work around this include running the tests with a small heap (-Xmx5m).
With less free space to work with, the gc tries harder. On a default size heap it mostly
ignores System.gc(). Unfortunately the test framework does not make it easy to set -Xmx
on a per test / test group basis.
Similar effect could perhaps be achieved by allocating all except a small portion of the
available heap from within the vm using eg. new byte[].
There is also the jvmti ForceGarbageCollection method, but that would require us to have
a chunk of C code on each test platform, which is a pain.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira