6:32 a.m.
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
7:28 a.m.
New subject: [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
8:09 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-555) make memory leak tests more robust
[
https://jira.jboss.org/jira/browse/JBTM-555?page=com.atlassian.jira.plugi...
]
Jonathan Halliday commented on JBTM-555:
----------------------------------------
Maybe running the test with the gc.log and analysing it afterwards
would also be a sounded approach
In order to have a gc log to analyse, you have to force gc to run. If you can force gc to
run, you don't need the log...
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
9:10 a.m.
New subject: [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:
-------------------------------------
Well, unless I mistaken, GC is almost always running, what is not always doing is cleaning
the memory,at least not all memory, for this we have to wait for a full GC, which is I
think what you want to trigger...
What I'm suggesting is not really trying to get help from whatever the GC can do, but
comparing memory consumption between releases, to see if some test now seems to be more
memory consuming than before. This is more an other approach to the situation (how can
detect memory leak) rather than a fix for the issue (find a way to trigger a full GC so
jvm cleans the all memory).
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
9:49 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-555) make memory leak tests more robust
[
https://jira.jboss.org/jira/browse/JBTM-555?page=com.atlassian.jira.plugi...
]
Jonathan Halliday commented on JBTM-555:
----------------------------------------
comparing memory consumption between releases
Without full gc you don't have reliable numbers for any release, so you have nothing
meaningful to compare.
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
11:27 a.m.
New subject: [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:
-------------------------------------
yes, you 're right... Well, if I got the time, I'll take a look at OpenJDK source
code for you, they are bound to have some kind of mechanism to test the GC efficiency,
with any luck it'll be reusable for JBossTS.
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
12:39 p.m.
New subject: [JBoss JIRA] Updated: (JBTM-555) make memory leak tests more robust
[
https://jira.jboss.org/jira/browse/JBTM-555?page=com.atlassian.jira.plugi...
]
Jonathan Halliday updated JBTM-555:
-----------------------------------
Fix Version/s: 4.9.0
(was: future)
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: 4.9.0
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
12:39 p.m.
New subject: [JBoss JIRA] Commented: (JBTM-555) make memory leak tests more robust
[
https://jira.jboss.org/jira/browse/JBTM-555?page=com.atlassian.jira.plugi...
]
Jonathan Halliday commented on JBTM-555:
----------------------------------------
opted to use jboss profiler agent to force GC via the JVM TI. This only works on selected
platforms where the agent binary is available, so also moved the tests that need it to
their own group so they can be run separately.
use http://www.jboss.org/jbossprofiler/downloads/jboss-profiler-1.0.CR4.zip to compile
additional agents if new platform support is needed for the tests.
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: 4.9.0
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
7:17 a.m.
New subject: [JBoss JIRA] Closed: (JBTM-555) make memory leak tests more robust
[
https://jira.jboss.org/jira/browse/JBTM-555?page=com.atlassian.jira.plugi...
]
Jonathan Halliday closed JBTM-555.
----------------------------------
Resolution: Done
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: 4.9.0
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
5265
days inactive
5459
days old
jbossts-issues@lists.jboss.org
8 comments
2 participants
participants (2)
-
Jonathan Halliday (JIRA) -
Romain PELISSE (JIRA)