[Biojava-dev] Build system changes

[Michael Heuer]

On Wed, 21 Jan 2004, Thomas Down wrote:

> Once upon a time, Matthew Pocock wrote:
> >  --- Thomas Down <thomas at derkholm.net> wrote:
> > > adds up.  If all the test classes are hanging around
> > > indefintiely,
> > > and referncing lots of classes in BioJava, we might
> > > well have
> > > a bit source of leaking memory right there :-(.
> >
> > This could potentially be sorted by using multiple
> > ClassLoaders - if JUnit can be convinced to drop the
> > dead tests, then the class loader instance for those
> > tests will become unreachable and all it's classes can
> > be garbage collected.
>
> I don't think this is true: AFAICT modern VMs garbage collect classes
> in pretty much the same way they handle objects.  So long as
> references to the TestCase classes are dropped, then the garbage
> collector should handle the rest.

It's been a little while since I looked at the biojava test codebase to
see how things are partitioned there, but I've seen that TestCases within
in the same TestSuite are held onto, see

junit/framework/TestSuite.java

30  	private Vector fTests= new Vector(10);
...
88  	/**
89	 * Adds a test to the suite.
90	 */
91	public void addTest(Test test) {
92		fTests.addElement(test);
93	}


For another datapoint, the jakarta-commons collections codebase runs
nearly 10000 tests without memory problems, but its test code is
partitioned into many explicitly defined test suites.

   michael


>
> > This is beginning to sound like
> > heavy JUnit hackery though. Also, the overhead of
> > loading the needed biojava classes repeatedly may put
> > us back towards our original performance problems.
>
> I'd hope that the VM ought to do a reasonable job of this:
> really fundamental parts of the library, like symbols, get used
> in most tests, so I don't think they'll ever be unloaded.
>
> Even if the whole of BJ got unloaded after every test, we'd
> *still* be winning because it would save execing a fresh VM
> for every test.
>
>      Thomas.
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at biojava.org
> http://biojava.org/mailman/listinfo/biojava-dev
>