db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-23) just booting jdbc driver and shutting down seem to leak memory
Date Mon, 19 Sep 2005 07:59:55 GMT
     [ http://issues.apache.org/jira/browse/DERBY-23?page=all ]

Knut Anders Hatlen updated DERBY-23:

    Attachment: DERBY-23.diff

The memory leak comes from three sources:

1) The AntiGC thread is sometimes not terminated. This happens when
   Derby is shut down right after the driver is loaded, because the
   run() method in AntiGC starts with setting a boolean variable which
   is used to decide when the thread should stop. The same variable is
   set when a request to shut down Derby is sent, and if the shutdown
   is requested before the AntiGC thread has started running, the
   request to shut down Derby might not be noticed by AntiGC which
   will run forever.

Solution: Don't set the boolean variable in AntiGC's run() method. It
is enough that it is being set when the object is initialized.

2) Every time the driver is loaded, a new ThreadGroup is created. They
   don't seem to be garbage collected even when all their threads have

Solution: Set the daemon property on the ThreadGroups. This way a
ThreadGroup will be destroyed when its last running thread (or thread
group) is destroyed.

3) The Java Heap Analysis Tool reported that a huge number of
   ContextManager and ContextService objects were kept in the
   heap. The objects were not accessible from the root set, but they
   were not garbage collected, probably because of some cyclic
   references which the gc cannot handle.

Solution: Break the reference cycle by nulling out the references to
the lists of ContextManagers when ContextService objects are stopped.

The attached patch seems to fix the problems mentioned above. Derbyall
runs fine, and top reports that the memory usage does not increase
when running a loop where the driver is loaded (with
Class.forName("org...EmbeddedDriver").newInstance()) and unloaded
(with DriverManager.getConnection("jdbc:derby:;shutdown=true")). That
is, the memory usage of course increased during the first iteration,
but not during the approximately 8.5 million next ones.

I will submit tests later.

> just booting jdbc driver and shutting down seem to leak memory
> --------------------------------------------------------------
>          Key: DERBY-23
>          URL: http://issues.apache.org/jira/browse/DERBY-23
>      Project: Derby
>         Type: Bug
>   Components: Services
>     Versions:
>     Reporter: Tulika Agrawal
>     Assignee: Knut Anders Hatlen
>     Priority: Minor
>  Attachments: DERBY-23.diff, DERBY-23.stat
> Reporting for Daniel John Debrunner.
> Doing simple boot and shutdown of the driver in a loop
> seem to grow the heap forever:
> new org.apache.derby.jdbc.EmbeddedDriver(); //boot the driver
> DriverManager.getConnection("jdbc:derby:;shutdown=true"); 
> //shutdown the cloudscape instance completely
> after booting and shutting down 1516 times, memory used is  
> ~~41931056 bytes.
> Sample GC Output:
> 1931.93: [Full GC 43484K->43243K(65088K), 0.1779751 secs]
> 1933.13: [Full GC 43511K->43270K(65088K), 0.1914383 secs]
> 1934.47: [Full GC 43538K->43297K(65088K), 0.1808878 secs]
> 1935.68: [Full GC 43564K->43324K(65088K), 0.4461623 secs]
> 1937.43: [Full GC 43591K->43350K(65088K), 0.1842980 secs]
> 1938.63: [Full GC 43617K->43377K(65088K), 0.1873431 secs]
> 1939.85: [Full GC 43644K->43404K(65088K), 0.1948505 secs]
> 1941.07: [Full GC 43671K->43430K(65088K), 0.1790895 secs]

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message