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
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
take memory reading
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:
For more information on JIRA, see: http://www.atlassian.com/software/jira