On Jun 14 2013, at 04:06 , Alan Bateman wrote: > On 14/06/2013 00:53, Mike Duigou wrote: >> Hello all; >> >> This is a small change to the make test target with big consequences. It >> enables concurrent running of tests. The number of simultaneous test jobs is >> the same as number of build jobs. >> >> This issue probably should have been combined with 8014819 as the two issues >> have been tested together. Thanks go to Amy Lu and Alan Bateman for their >> feedback and experience reports with concurrent testing. >> >> JPRT is not impacted by this change since it invokes the test/Makefile >> directly. >> >> Mike >> >> diff -r b40d24f793d2 common/makefiles/Main.gmk >> --- a/common/makefiles/Main.gmk Tue Jun 04 10:36:00 2013 +0200 >> +++ b/common/makefiles/Main.gmk Thu Jun 13 16:47:45 2013 -0700 >> @@ -183,7 +183,7 @@ >> test: images test-only >> test-only: start-make >> @$(call TargetEnter) >> - @($(CD) $(SRC_ROOT)/test&& $(BUILD_LOG_WRAPPER) $(MAKE) -j1 -k >> JT_HOME=$(JT_HOME) MAKEFLAGS= PRODUCT_HOME=$(JDK_IMAGE_DIR) >> JPRT_JAVA_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) $(TEST)) || true >> + @($(CD) $(SRC_ROOT)/test&& $(BUILD_LOG_WRAPPER) $(MAKE) -j1 -k >> MAKEFLAGS= JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) >> JPRT_JAVA_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) >> CONCURRENCY=$(JOBS) $(TEST)) || true >> @$(call TargetExit) >> >> # Stores the tips for each repository. This file is be used when >> constructing the jdk image and can be >> > This looks goods to me as $(JOBS) is about right for the jdk repository.
I can't speak to optimal performance but it is also sufficient for a successful run of langtools on a 24-core x64 linux box, a 2 core OSX box, and a single core linux x86 virtual box. If it turns out there is a more optimal way to run tests we can tweak the setting. > I think Jon mentioned somewhere (quality-discuss perhaps) that > -concurrency:auto might be too much for the langtools tests given the number > of compute-bound combo tests. I don't know if this is a concern here. I found -concurrency:auto generated too many jobs on the machines I use. -concurrency:$(JOBS) is currently always smaller than -concurrency:auto. $JOBS is currently approximately min(16, min($(CORES),$(MEMORY) / 1100M))) If we find that $JOBS ends up being too high in some cases it's probably an indicator that we need to adjust the $(JOBS) sizing. Mike
