|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
|
|
testing memory leaksHi all I'm looking for a way to force garbage collection to run, as I need it in order to write meaningful memory leak tests. As far as I can tell, there is no way for force gc from inside the jvm, short of hacks like allocating all the remaining free memory. The best I can come up with so far is a bit of native code to call gc via the jvmti. This is a pain, as it means compiling for every test platform. Anyone got a better idea? Thanks Jonathan. -- ------------------------------------------------------------ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland) _______________________________________________ jboss-development mailing list jboss-development@... https://lists.jboss.org/mailman/listinfo/jboss-development |
|
|
Re: testing memory leaksJonathan Halliday wrote:
> Hi all > > I'm looking for a way to force garbage collection to run, as > I need it in order to write meaningful memory leak tests. > > As far as I can tell, there is no way for force gc from > inside the jvm, short of hacks like allocating all the > remaining free memory. > > The best I can come up with so far is a bit of native code > to call gc via the jvmti. This is a pain, as it means > compiling for every test platform. We have a classloader leak test in the AS that does both of the above. The former caused all kinds of hudson issues, usually because the JVM gets into strange states/dealys when you repeatedly fill all heap space. The latter however works very reliably. The solution to the portability problem is IMO, to separate the leak testing from the main testsuite, and then run that on a dedicated platform. If you have a real Java memory leak, it should show up on every OS, but probably not every JVM. -- Jason T. Greene JBoss, a division of Red Hat _______________________________________________ jboss-development mailing list jboss-development@... https://lists.jboss.org/mailman/listinfo/jboss-development |
|
|
Re: testing memory leaksJBoss Profiler has something there to force memory leaks for you via
jmti. On 4 Nov 2009, at 13:49, Jason T. Greene wrote: > Jonathan Halliday wrote: >> Hi all >> >> I'm looking for a way to force garbage collection to run, as >> I need it in order to write meaningful memory leak tests. >> >> As far as I can tell, there is no way for force gc from >> inside the jvm, short of hacks like allocating all the >> remaining free memory. >> >> The best I can come up with so far is a bit of native code >> to call gc via the jvmti. This is a pain, as it means >> compiling for every test platform. > > We have a classloader leak test in the AS that does both of the above. > The former caused all kinds of hudson issues, usually because the JVM > gets into strange states/dealys when you repeatedly fill all heap > space. > > The latter however works very reliably. The solution to the > portability > problem is IMO, to separate the leak testing from the main testsuite, > and then run that on a dedicated platform. If you have a real Java > memory leak, it should show up on every OS, but probably not every > JVM. > > -- > Jason T. Greene > JBoss, a division of Red Hat > _______________________________________________ > jboss-development mailing list > jboss-development@... > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development@... https://lists.jboss.org/mailman/listinfo/jboss-development |
|
|
Re: testing memory leaksByteman? :-)
You could inject a rule that invokes the GC when a certain method is invoked or condition exists? Byteman is ridiculously easy to setup and use, especially for testing like this. On 11/04/2009 08:55 AM, Kabir Khan wrote: > JBoss Profiler has something there to force memory leaks for you via > jmti. > > On 4 Nov 2009, at 13:49, Jason T. Greene wrote: > >> Jonathan Halliday wrote: >>> Hi all >>> >>> I'm looking for a way to force garbage collection to run, as >>> I need it in order to write meaningful memory leak tests. >>> >>> As far as I can tell, there is no way for force gc from >>> inside the jvm, short of hacks like allocating all the >>> remaining free memory. >>> >>> The best I can come up with so far is a bit of native code >>> to call gc via the jvmti. This is a pain, as it means >>> compiling for every test platform. >> >> We have a classloader leak test in the AS that does both of the above. >> The former caused all kinds of hudson issues, usually because the JVM >> gets into strange states/dealys when you repeatedly fill all heap >> space. >> >> The latter however works very reliably. The solution to the >> portability >> problem is IMO, to separate the leak testing from the main testsuite, >> and then run that on a dedicated platform. If you have a real Java >> memory leak, it should show up on every OS, but probably not every >> JVM. >> >> -- >> Jason T. Greene >> JBoss, a division of Red Hat >> _______________________________________________ >> jboss-development mailing list >> jboss-development@... >> https://lists.jboss.org/mailman/listinfo/jboss-development > > _______________________________________________ > jboss-development mailing list > jboss-development@... > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development@... https://lists.jboss.org/mailman/listinfo/jboss-development |
|
|
Re: testing memory leaksTake a look at https://svn.jboss.org/repos/jbossas/projects/aop/trunk/aop/src/test/java/org/jboss/test/aop/memoryleaks/MemoryLeakTester.java
or MemoryLeakTestCase.java to see it in use On 4 Nov 2009, at 13:55, Kabir Khan wrote: > JBoss Profiler has something there to force memory leaks for you via > jmti. > > On 4 Nov 2009, at 13:49, Jason T. Greene wrote: > >> Jonathan Halliday wrote: >>> Hi all >>> >>> I'm looking for a way to force garbage collection to run, as >>> I need it in order to write meaningful memory leak tests. >>> >>> As far as I can tell, there is no way for force gc from >>> inside the jvm, short of hacks like allocating all the >>> remaining free memory. >>> >>> The best I can come up with so far is a bit of native code >>> to call gc via the jvmti. This is a pain, as it means >>> compiling for every test platform. >> >> We have a classloader leak test in the AS that does both of the >> above. >> The former caused all kinds of hudson issues, usually because the JVM >> gets into strange states/dealys when you repeatedly fill all heap >> space. >> >> The latter however works very reliably. The solution to the >> portability >> problem is IMO, to separate the leak testing from the main testsuite, >> and then run that on a dedicated platform. If you have a real Java >> memory leak, it should show up on every OS, but probably not every >> JVM. >> >> -- >> Jason T. Greene >> JBoss, a division of Red Hat >> _______________________________________________ >> jboss-development mailing list >> jboss-development@... >> https://lists.jboss.org/mailman/listinfo/jboss-development > > _______________________________________________ > jboss-development mailing list > jboss-development@... > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development@... https://lists.jboss.org/mailman/listinfo/jboss-development |
|
|
Re: testing memory leaks+1
Clebert has also done some stuff in this area, perhaps he wants to chime in... On 04/11/09 13:55, Kabir Khan wrote: > JBoss Profiler has something there to force memory leaks for you via > jmti. > > On 4 Nov 2009, at 13:49, Jason T. Greene wrote: > > >> Jonathan Halliday wrote: >> >>> Hi all >>> >>> I'm looking for a way to force garbage collection to run, as >>> I need it in order to write meaningful memory leak tests. >>> >>> As far as I can tell, there is no way for force gc from >>> inside the jvm, short of hacks like allocating all the >>> remaining free memory. >>> >>> The best I can come up with so far is a bit of native code >>> to call gc via the jvmti. This is a pain, as it means >>> compiling for every test platform. >>> >> We have a classloader leak test in the AS that does both of the above. >> The former caused all kinds of hudson issues, usually because the JVM >> gets into strange states/dealys when you repeatedly fill all heap >> space. >> >> The latter however works very reliably. The solution to the >> portability >> problem is IMO, to separate the leak testing from the main testsuite, >> and then run that on a dedicated platform. If you have a real Java >> memory leak, it should show up on every OS, but probably not every >> JVM. >> >> -- >> Jason T. Greene >> JBoss, a division of Red Hat >> _______________________________________________ >> jboss-development mailing list >> jboss-development@... >> https://lists.jboss.org/mailman/listinfo/jboss-development >> > _______________________________________________ > jboss-development mailing list > jboss-development@... > https://lists.jboss.org/mailman/listinfo/jboss-development > -- Sent from my BBC Micro Model B Tim Fox JBoss HornetQ - putting the buzz in messaging http://hornetq.org http://hornetq.blogspot.com/ http://twitter.com/hornetq irc://irc.freenode.net:6667#hornetq fox@... _______________________________________________ jboss-development mailing list jboss-development@... https://lists.jboss.org/mailman/listinfo/jboss-development |
| Free embeddable forum powered by Nabble | Forum Help |