[
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++)
BIG_STRING_BUFFER.append("123456789012345678901234567890");
}
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 {
Thread.sleep(10);
}
}
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: 10.5.2.0
> 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 - 10.5.1.2 - (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) prio=5
> 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
> Code))
> 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
> Code))
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
