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] Updated: (DERBY-1614) Test harness overrides heap size settings when starting Network Server
Date Wed, 02 Aug 2006 12:05:14 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1614?page=all ]

John H. Embretsen updated DERBY-1614:
-------------------------------------

    Attachment: DERBY-1614_v1.diff

Attatching patch 'DERBY-1614_v1.diff', which fixes the following issues:

   * harness/NetServer.java: Changes harness behaviour so that no heap settings for the Network
Server are set if either initial or max heap size has already been set in the jvmflags argument
of the NetServer constructor. Prior to this change, the harness would override heap size settings
from the command line or test property files unless both old heap flags (-ms or -mx) AND "new"
heap flags (-Xms or -Xmx) had been set. The harness would also treat initial and max sizes
independently, which caused incompatibilities in some situations (see DERBY-1564). 
   * Behavior has *not* changed in scenarios where jvmflags (when passed to NetServer) is
null or empty, in which case no extra flags are added.

   * testing/README.htm:
      * fixed small bug in jvmflags example (missing '-' in front of first flag).
      * changed jvmflags example from using -ms and -mx to using -Xms and -Xmx, since the
latter flags are documented non-standard jvm options, while the former flags are deprecated
(at least in Sun's current Java launchers...), and we are just lucky that they still work.
      * added comment about possible consequences of setting only initial or only max heap
size using jvmflags.


svn stat:

M      java/testing/README.htm
M      java/testing/org/apache/derbyTesting/functionTests/harness/NetServer.java

The patch has been tested with individual test runs of lang/wisconsin.java and lang/forupdate.java.
Derbyall is still running at the time of writing this...

Please review this patch.


Other patch comments:
------------------------------------------

- If only initial or only max heap size is set using the jvmflags harness property, no extra
flags will be added by NetServer. This reduces the risk of incompatibilities between initial
and max values, but it is still possible (which is also the case with any other Java application).
For Sun's HotSpot JVM version 1.5, the default initial heap size is 2 MB, and the default
max heap size is 64 MB [1]. Hence: 
   - if jvmflags specifies a max value that is smaller than 2 MB 
     (or whatever is the default for a particular JVM), without also 
     setting an initial heap size, or
   - if jvmflags specifies an initial value that is larger than the 
     default max heap size for a particular JVM (e.g. 64 MB),
     without also setting a max heap size,
   - the Java launcher will fail with the message like this:

> Error occurred during initialization of VM
> Incompatible initial and maximum heap sizes specified

- Current behavior depends on the JVM behavior described in DERBY-1091. Specifically, this
means that as long as all test JVMs use the _last_ value of each heap setting if multiple
values are specified, and old and new versions of heap flags are treated equally, we are all
good.

- I was tempted to remove the following line in NetServer.java (but didn't):

     jvm.setNoasyncgc(true); // -noasyncgc

  since no JVM that I know of supports the -noasyncgc option anymore. The last HotSpot VM
where that option was supported was supposedly version 1.1 [2]. Besides, I do not see any
reason why we would want to turn of dynamic garbage collection for the server when running
tests. Anyway, I'll let it be, since most jdk* classes in the harness ignore the setting anyway.


[1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/java.html and
      http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html

[2] http://forums.java.net/jive/thread.jspa?threadID=16315&tstart=0


> 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
>
>
> 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

        

Mime
View raw message