On Fri, Aug 8, 2014 at 9:35 AM, Uwe Schindler <u...@thetaphi.de> wrote: > Hi Dawid, > > Thanks for the very good explanation! Indeed the main problem with > tests.iters is the static initializers. Maybe put that explanation into the > Wiki! I sometimes also need to remember it, so it should be documented. > > One (only theoretical) way to solve the whole thing could be: > Load the class(es) in a separate classloader for every repeated execution,... > but of course this will very fast blow up your permgen (java 6, 7) or > anything else we don't know about (java 8). In fact the separate classloader > approach is not different from Mike's scripts, just that Mike's script > creates a new classloader by forking a new JVM. In fact I don't think the > separate classloader approach would be much faster, because the class clones > will all have separate compilation paths in Hotspot, so Hotspot cannot share > the same assembler code. So except the JVM startup time, you gain nothing. > Just permgen issues :-)
The big thing the python beasting scripts avoids is all the ant overhead to just get to the point where it actually spawns the JVM to run the test. Really, that's all the beasting script does: directly spawn the JVM on the test runner (after running "ant test-compile" up front) and then parse its output/events. The distributed test runner, which uses rsync/ssh to run tests on N machines, is very different from the beasting script: it runs all Lucene's tests (instead of a single test over and over) across N JVMs on M machines. It "cheats" by taking the union of all CLASSPATHs ... but this is a huge win because it means all testing is fully concurrent, not just concurrent within one module. This script can also repeat, which means once all lucene tests finish, re-en-queue all of them again. Mike McCandless http://blog.mikemccandless.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org