db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1614) Test harness overrides heap size settings when starting Network Server
Date Fri, 04 Aug 2006 14:17:15 GMT
    [ 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
+ 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
- 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#
[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:
>         Environment: Test frameworks DerbyNet and DerbyNetClient
>            Reporter: John H. Embretsen
>         Assigned To: John H. Embretsen
>             Fix For:
>         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


View raw message