[ http://issues.apache.org/jira/browse/DERBY-1614?page=comments#action_12425754 ] John H. Embretsen commented on DERBY-1614: ------------------------------------------
I really appreciate the historical information, Myrna, it is certainly useful in figuring out what the original intention must have been :) I was not aware of the change to the jvmflags behavior in DERBY-121. It seems to me that this change was done "because the test for DERBY-121 requires extra heap memory for the server's JVM", and that the intention was, as Myrna pointed out, to make sure that the "default" heap size settings (min 16 MB, max 32 MB) that had been there since before Derby/Cloudscape was open sourced were overridden by the test-specific settings set by jvmflags. I think the people involved at that time failed to notice that the patch for DERBY-121 also introduced a significant change to the behavior of the test harness; going from always setting the "default" heap size flags, to only setting them if jvmflags is not null and not the empty String (when a heap size flag was set in jvmflags, the "default" value for that flag was overridden). Please correct me if I am wrong... I'd like to go through the two options (well, there is a third option: "C) Don't change anything") and look at some pros (+) and cons (-) of each one. I am rephrasing A) and B) slightly... A) Do not set any heap size flags for the network server apart from those specified in jvmflags - Server heap sizes will not be the same for every JVM, since the default sizes depends on JVM vendor, JVM version, OS, hardware etc. [1, 2, 3] + The fact that test results may depend on the JVM which is used (at least when it comes to OutOfMemoryErrors) is more in line with how the product is used in production. Here I assume that most users of Derby don't change the memory settings of the JVM they use for the Network Server. + If a test fails with OutOfMemoryError on JVMs with a small default max heap size, but not on other JVMs, we immediately know that this particular test requires a certain amout of memory, and can take appropriate action. + Network Server instances started by the test harness via NetServer have the same heap size values as server instances started directly from tests, by default. + Test harness complexity is reduced + Current default behavior when jvmflags is not used is not changed B) Always set heap size flags (min and max size) for the network server, unless either -ms, -Xms, -mx or -Xmx has been specified in jvmflags + (?) All tests run with the same heap sizes on all platforms, unless jvmflags specifies non-default values - this may reduce the number of variables to consider when trying to figure out a test failure? - It is hard to determine default heap size values that are suitable for all test platforms (from J2ME devices to multi-processor servers). The current values are min. 16 MB, max. 32 MB, but this has not been used by default since SVN 179859 (June 2005). - Current behavior (not setting any heap flags unless jvmflags is set) is changed back to old behavior (always setting heap flags), which may cause more tests to fail (since the harness default is smaller than the default of the most common test JVMs). - See pros of option A) C) Don't change anything + Nothing is changed - It is simply not very useful that the harness sets heap size flags whenever any jvm option is set using the jvmflags property, but not otherwise. I see a trend in that we are becoming more interested in running derbyall with certain options, for example enabling 64-bit datamodel (-d64) or setting a property used by a code coverage analysis tool (-Demma.verbosity.level=silent). Using "passive" flags has undesirable consequences. So, with this I hope anyone interested has captured my thoughts around this issue. I intend to provide a patch implementing option A) soon. (If tests are not successful, I will recommend that the current (v2) patch is committed to trunk/10.2, and that we postpone further action until the 10.2 release is out.) Please comment if you have other opinions. [1] http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html#0.0.0.%20Total%20Heap%7Coutline [2] http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html#0.0.0.0.%20Heap%20Size%7Coutline [3] http://java.sun.com/docs/hotspot/gc5.0/ergo5.html > Test harness overrides heap size settings when starting Network Server > ---------------------------------------------------------------------- > > Key: DERBY-1614 > URL: http://issues.apache.org/jira/browse/DERBY-1614 > Project: Derby > Issue Type: Bug > Components: Test > Affects Versions: 10.2.0.0 > Environment: Test frameworks DerbyNet and DerbyNetClient > Reporter: John H. Embretsen > Assigned To: John H. Embretsen > Fix For: 10.2.0.0 > > Attachments: DERBY-1614_v1.diff, DERBY-1614_v2.diff > > > Test specific heap size settings can be passed to the test harness using the > jvmflags system property, for example in a <testname>_app.properties file or > at the command line when starting a test, e.g "-Djvmflags=-Xms32m^-Xmx32m". > The test harness almost always overrides such settings when starting a new > Network Server using the > org.apache.derbyTesting.functionTests.harness.NetServer class of the test > harness. Currently, if _either_ -ms _or_ -Xms is missing from the jvmflags, > NetServer.start() adds -ms16777216. Also, if _either_ -mx _or_ -Xmx is > missing from the jvmflags, NetServer.start() adds -ms33554432. This has been > the case since SVN revision 420048 (July 8, 2006). > Earlier revisions did not override the heap settings unless the newer -Xms or > -Xmx flags were used instead of the -ms and -mx flags. A patch for DERBY-1091 > attempted (among other things) to make the harness recognize the newer flags > as well as the older flags, but the resulting behavior is (most likely) not > as intended. > If a test is run in either the DerbyNet framework or the DerbyNetClient > framework, the test-specific JVM flags should (probably) be used for the > Network Server JVM as well as the test JVM. Currently, even if non-default > heap size flags are passed to the harness, the server JVM will ignore these > settings since the harness adds -ms and/or -mx flags _after_ all other heap > flags. The exception is if both new and old versions of heap flags are passed > to the harness, e.g: > jvmflags=-ms32m^-Xms32m^-mx128m^-Xmx128m > Here is the code causing this behaviour: > if (setJvmFlags && ((jvmflags.indexOf("-ms") == -1) || > (jvmflags.indexOf("-Xms") == -1))) > // only setMs if no starting memory was given > jvm.setMs(16*1024*1024); // -ms16m > if (setJvmFlags && ((jvmflags.indexOf("-mx") == -1) || > (jvmflags.indexOf("-Xmx") == -1))) > // only setMx if no max memory was given > jvm.setMx(32*1024*1024); // -mx32m -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
