db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Harryman <Robert.Harry...@Sun.COM>
Subject derby Static refs to log objects
Date Tue, 22 May 2007 15:37:51 GMT
Hello,

I am deploying a module into the Solaris Common Agent container (JMX/JDMK).
I carefully monitored my module classes to make sure all objects we GC'd 
after the undeploy.

Next I added  classloading of the embedded derby driver, did a shutdown 
of the database and unregistered the
driver. Using jmap/jhat (jdk 1.6) I see that all my objects are being 
kept alive and that there are a lot
of derby static refs around to java.util.logging.Logger. This leak will 
force me to bounce the container during
redeploy since PermGen will eventually exhaust and cause an out of 
memory condition.

Is this a known problem? Does derby/javaDB have a bug against static 
references to log objects?

Any guidance is very much appreciated.
Sincerely,
Bob Harryman

The jhat reported static refs:

Rootset references to class java.util.logging.Logger (excludes weak refs)
References to class java.util.logging.Logger (84 bytes)
Java Static References
.....
Static reference from 
org.apache.derby.impl.services.monitor.BaseMonitor.class$org$apache$derby$iapi$services$monitor$PersistentService

(from class org.apache.derby.impl.services.monitor.BaseMonitor) :
--> class org.apache.derby.iapi.services.monitor.PersistentService (84 
bytes) (??:)
--> com.sun.cacao.impl.ModuleClassLoader@0xf0037cd8 (79 bytes) (??:)
--> class com.sun.cacao.impl.ModuleClassLoader (84 bytes) (static field 
logger:)
--> java.util.logging.Logger@0xeff007e0 (58 bytes) (??:)
--> class java.util.logging.Logger (84 bytes)
Static reference from 
org.apache.derby.impl.services.monitor.BaseMonitor.class$org$apache$derby$io$StorageFactory

(from class org.apache.derby.impl.services.monitor.BaseMonitor) :
--> class org.apache.derby.io.StorageFactory (84 bytes) (??:)
--> com.sun.cacao.impl.ModuleClassLoader@0xf0037cd8 (79 bytes) (??:)
--> class com.sun.cacao.impl.ModuleClassLoader (84 bytes) (static field 
logger:)
--> java.util.logging.Logger@0xeff007e0 (58 bytes) (??:)
--> class java.util.logging.Logger (84 bytes)


Here is how I'm doing the analysis:

$  /usr/java/bin/jps -v | grep ontainer
10604 ContainerPrivate -Xms16M -Xmx128M -Dcom.sun.management.jmxremote 
-Dfile.encoding=utf-8 -Xdebug -Xnoagent -Djava.compiler=NONE 
-Xrunjdwp:transport=dt_socket,server=y,address=9091,suspend=n 
-Djavax.management.builder.initial=com.sun.jdmk.JdmkMBeanServerBuilder 
-Dcacao.config.dir=/home/bharryma/tools/cacao/2.1_b19/cacao_2.1/etc/cacao/instances/default
$ rm leak
$  /usr/java/bin/jmap -dump:format=b,file=leak 10604
Dumping heap to /home/bharryma/projects/isns/dumps/leak ...
Heap dump file created
$  /usr/java/bin/jhat -J-Xmx512m leak
Reading from leak...
Dump file created Tue May 22 09:14:36 MDT 2007
Snapshot read, resolving...
Resolving 70073 objects...
Chasing references, expect 14 dots..............
Eliminating duplicate references..............
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.


Mime
View raw message