Name: rmT116609 Date: 07/11/2001


java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)
AND
java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Server VM (build 1.4.0-beta-b65, mixed mode)
java version "1.3.0"
AND
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

When using the HotSpot VM on Windows NT, every call to java.sql.ResultSet's
getTimestamp() method loses about 40 bytes that is not detected by the
java.lang.Runtime's totalMemory() and freeMemory() calls. It appears to occur
only when using the HotSpot VM - the classic VM did not show any memory leaks
for the same code.

Using the JDBC-ODBC bridge, I queried a database table containing 160K records,
one column of which was a Timestamp, and Windows Task Manager showed the memory
used by the java process went up 6.2M. Runtime's totalMemory() showed it going
up as well but when I minimized the app, Windows Task Manager showed that most
of the memory for the process had been freed but the total memory used by the
system did not change - it still showed a loss of 6.2M each time the code in
the loop was called. This occured when calling ResultSet's getTimestamp()
method and did not occur when calling either getDate() or getTime().

Here is a portion of the code I ended up with in trying to find the source of
the problem:

...
for (int i = 0; i < 10; i++)
{
System.out.println(i);
ResultSet rs = stmt.executeQuery("Select * from TestTable");

printMemory();
while (rs.next())
{
Timestamp ts = rs.getTimestamp(5);
// java.sql.Date date = rs.getDate(5);
// java.sql.Time time = rs.getTime(5);
}
printMemory();
rs.close();
}
...
private void printMemory()
{
long total = Runtime.getRuntime().totalMemory();
long free = Runtime.getRuntime().freeMemory();
long used = total - free;

System.gc();
System.out.println("Total = "+nf.format(total)+" Used = "+nf.format
(used)+" Free = "+nf.format(free));
}



Here is the output for the above code:

0
  Total = 2,031,616 Used = 846,816 Free = 1,184,800
  Total = 2,031,616 Used = 1,004,800 Free = 1,026,816
1
  Total = 2,031,616 Used = 644,672 Free = 1,386,944
  Total = 2,031,616 Used = 995,408 Free = 1,036,208
2
  Total = 2,031,616 Used = 580,152 Free = 1,451,464
  Total = 2,031,616 Used = 931,104 Free = 1,100,512
3
  Total = 2,031,616 Used = 583,128 Free = 1,448,488
  Total = 2,031,616 Used = 934,080 Free = 1,097,536
4
  Total = 2,031,616 Used = 580,152 Free = 1,451,464
  Total = 2,031,616 Used = 931,104 Free = 1,100,512
5
  Total = 2,031,616 Used = 583,128 Free = 1,448,488
  Total = 2,031,616 Used = 934,080 Free = 1,097,536
6
  Total = 2,031,616 Used = 580,152 Free = 1,451,464
  Total = 2,031,616 Used = 931,104 Free = 1,100,512
7
  Total = 2,031,616 Used = 583,128 Free = 1,448,488
  Total = 2,031,616 Used = 934,080 Free = 1,097,536
8
  Total = 2,031,616 Used = 580,152 Free = 1,451,464
  Total = 2,031,616 Used = 931,104 Free = 1,100,512
9
  Total = 2,031,616 Used = 583,128 Free = 1,448,488
  Total = 2,031,616 Used = 934,080 Free = 1,097,536



Windows Task Manager showed the process Mem Usage to be roughly the following
for the same code:

0 12.5M
1 20.6M
2 26.8M
3 32.9M
4 39.1M
5 45.5M
6 51.6M
7 57.0M
8 64.1M
9 69.7M

------------------------- TestTimestamp.java ----------------------------------------

package testtimestamp;

import java.text.*;
import java.util.*;
import java.sql.*;

public class TestTimestamp
{
public static void main(String[] args)
{
testTimestampMemLeak();
}

private static void testTimestampMemLeak()
{
try
{
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Connection con = DriverManager.getConnection("jdbc:odbc:yourDataSource", "yourName", "yourPassword");

Statement stmt = con.createStatement();

for (int i = 0; i < 10; i++)
{
System.out.println(i);

ResultSet rs = stmt.executeQuery("Select * from YourTable");

printMemory();
while (rs.next())
{
// java.sql.Date date = rs.getDate(5);
// java.sql.Time time = rs.getTime(5);
Timestamp ts = rs.getTimestamp(5);
}
printMemory();

rs.close();
rs = null;
}

con.close();
con = null;
}
catch (Exception ex)
{
ex.printStackTrace();
}
}

private static void printMemory()
{
NumberFormat nf = NumberFormat.getInstance();
long total = Runtime.getRuntime().totalMemory();
long free = Runtime.getRuntime().freeMemory();
long used = total - free;

System.gc();
System.out.println("Total = "+nf.format(total)+" Used = "+nf.format(used)+" Free = "+nf.format(free));
}
}


------------------------------------------------------------------------------------------------------------


1) Exact steps to reproduce the problem.

        (Setup your database as described below and change the settings in the attached file to your settings)
        Compile and run the attached file

2)Complete test case that will reproduce the problem.

        Attached

3) Actual and expected behaviour of the test case.

        The behavior is the same as described in the original bug

4) Complete database information needed to reproduce the problem.

        Microsoft SQL Server 2000
        Database table includes a column of type 'datetime'

        or

        Oracle
        Database table includes a column of type 'date'

        !!!Fill the table with about 160K records before the test (a common situation for our application)!!!


5)The exact text of any error message(s) that appeared.

        Start Windows Task Manager before running the app and look at the Total Memory or Mem Usage
        After each loop of the code the Mem Usage goes up by about 6 Meg and is never released while
        the app is running

6)System Configuaration on which the problem is reproducible.

        Windows NT
        Microsoft Windows 2000 Professional
        Version 5.0.2195 Build 2195
        Total Physical Memory 261,680 KB
        
7) Any other additional information that you think is relavant to the problem.

        The problem does not show up when running the -classic version of the runtime - only when using HotSpot
        Calling rs.getDate() or rs.getTime() do not exhibit memory leak problems - just rs.getTimestamp()
        Other developers at this site have tried the same code with similar results
        I'm not certain, but it doesn't appear that the type of database makes a difference


I hope this helps. I would be happy to provide any more information that you might need to help find the
source of this bug. This is an urgent problem for us and may cause us to push our ship dates back.

(Review ID: 127641)
======================================================================