db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-23) just booting jdbc driver and shutting down seem to leak memory
Date Mon, 19 Sep 2005 08:30:44 GMT
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

Mime
View raw message