db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-4200) client side OutOfMemoryError running derbnetclientmats:jdbcapi/derbyStress
Date Thu, 30 Jun 2011 13:29:28 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057815#comment-13057815

Kathey Marsden commented on DERBY-4200:

Since we have only ever seen this on the IBM jvms, I started to wonder if this might in fact
be a jvm bug. I wondered if perhaps the garbage collector should wait until the finalizer
catches up before throwing the out of memory.  To experiment I tried making a class with a
sleep in the finalize method to see if the Sun JVM waits but it does not wait in this case
and runs out of memory with the sleep.  Here is the code I used:
public class GCWontWait {

    private static StringBuffer BIG_STRING_BUFFER;
    static {
	BIG_STRING_BUFFER  = new StringBuffer(30000);
	for (int i = 0; i<1000; i++)

    public static void main(String[] args) {

	SlowString s;
	for (int i=0;i < 100000;i++) {
	    s = new SlowString(BIG_STRING_BUFFER);
	    if ((i % 100) == 0)
		System.out.println("i = " + i);



public  class SlowString  {

	String v;

	public SlowString(StringBuffer s) {
	    v = new String(s);

    public void finalize() throws Throwable {

java -Xmx16m -cp . GCWontWait

With the Sun JVM failed with OOM after only 200 instantiations
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode)

IBM JDK 1.6  actually did much better on the allocation and instantiated all 100000 objects.
java version "1.6.0"
Java(TM) SE Runtime Environment (build pwi3260sr9fp1-20110208_03(SR9 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260sr9-201102
03_74623 (JIT enabled, AOT enabled)
J9VM - 20110203_074623
JIT  - r9_20101028_17488ifx3
GC   - 20101027_AA)
JCL  - 20110203_01

I am not sure what this means except that Sun doesn't wait for the finalizer either. Maybe
the IBM jvm is just reusing the duplicate strings more efficiently.

> client side OutOfMemoryError running derbnetclientmats:jdbcapi/derbyStress
> --------------------------------------------------------------------------
>                 Key: DERBY-4200
>                 URL: https://issues.apache.org/jira/browse/DERBY-4200
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions:
>         Environment: java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pxi32devifx-20070806 (SR5a))
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20070426 (JIT enabled)
> J9VM - 20070420_12448_lHdSMR
> JIT  - 20070419_1806_r8
> GC   - 200704_19)
> JCL  - 20070725
> SUSE linux running on vmware.
>            Reporter: Kathey Marsden
>            Assignee: Mamta A. Satoor
>         Attachments: heapdump.20090428.084024.25679.phd, javacore.20090428.084024.25679.txt,
vmware10_5_SR10HeapDump.phd, vmware10_5_SR7HeapDump.phd, windows10_5_HeapDump.phd
> On the nightly run for 4/27 - - (769232), I saw client jdbcapi/derbystress.java
 run out of heap space.   The test has not failed like this before on the same machine with
the same JVM, and the one checkin on that day DERBY-3991 could not account for this failure.
> I will attach the javacore and heapdump.  Taking a quick look at the heap dump, it seems
to have a lot of client side Statement objects, which seems to be just the leak the test is
checking for.  Note: the test runs with 64MB heap.  It would be interesting to run with other
jvms and force a gc() and a heap dump at this point in the test and see if we still have a
lot of Statement objects or if this is a specific platform/JVM issue.
> The trace at the time of failure was :
> 1XMCURTHDINFO  Current Thread Details
> NULL           ----------------------
> 3XMTHREADINFO      "main" (TID:0x0808D300, sys_thread_t:0x0805CBC8, state:R, native ID:0x0000644F)
> 4XESTACKTRACE          at org/apache/derby/client/am/Cursor.allocateCharBuffer(Bytecode
PC:77(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/NetStatementReply.parseSQLDTARDarray(Bytecode
PC:77(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/NetStatementReply.parseQRYDSC(Bytecode
PC:10(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/NetStatementReply.parseOpenQuery(Bytecode
PC:104(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/NetStatementReply.parseOPNQRYreply(Bytecode
PC:14(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/NetStatementReply.readOpenQuery(Bytecode
PC:6(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/StatementReply.readOpenQuery(Bytecode
PC:7(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/NetStatement.readOpenQuery_(Bytecode
PC:11(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/am/Statement.readOpenQuery(Bytecode
PC:6(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/am/Statement.flowExecute(Bytecode PC:581(Compiled
> 4XESTACKTRACE          at org/apache/derby/client/am/Statement.executeQueryX(Bytecode
PC:3(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/am/Statement.executeQuery(Bytecode
PC:3(Compiled Code))
> 4XESTACKTRACE          at org/apache/derbyTesting/functionTests/tests/jdbcapi/derbyStress.testDerby3316(derbyStress.java:156)
> 4XESTACKTRACE          at org/apache/derbyTesting/functionTests/tests/jdbcapi/derbyStress.main(derbyStress.java:57(Compiled

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message