You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org> on 2005/09/19 09:59:55 UTC
[jira] Updated: (DERBY-23) just booting jdbc driver and shutting down seem to leak memory
[ http://issues.apache.org/jira/browse/DERBY-23?page=all ]
Knut Anders Hatlen updated DERBY-23:
------------------------------------
Attachment: DERBY-23.diff
DERBY-23.stat
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
finished.
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: 10.0.2.0
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-23) just booting jdbc driver and shutting
down seem to leak memory
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
It looks sound to me, but I would prefer a second opinion from
somebody more familiar with this area of the code before I commit the
patch.
Bernt
>>>>>>>>>>>> Knut Anders Hatlen (JIRA) wrote (2005-09-19 09:59:55):
> [ http://issues.apache.org/jira/browse/DERBY-23?page=all ]
>
> Knut Anders Hatlen updated DERBY-23:
> ------------------------------------
>
> Attachment: DERBY-23.diff
> DERBY-23.stat
>
> 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
> finished.
>
> 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: 10.0.2.0
> > 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:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
--
Bernt Marius Johnsen, Database Technology Group,
Sun Microsystems, Trondheim, Norway