0

I am learning OSGi as it is becoming popular now a days. I am using linux as my OS and OpenJDK as development environment. I have created few bundles A,B,C.. etc in OSGi equinox framwork.

I run OSGi framework using below command:

java -jar osgi-3.10.0-v20140606-1445.jar -console

now I installed and started A,B,C .. etc bundle in OSGi console. using linux top command I have observed memory and CPU utilization as below:

 PID   PPID USER     STAT   VSZ %VSZ %CPU COMMAND
 1972   422 root     S     368m  74%   3% java -jar osgi-3.10.0-v20140606-1445.jar -console

I observed that one of my bundle say B was causing high memory utilization. I uninstalled the bundle B from OSGi and again checked the memory usage. I found the same result with no change either in CPU usage or in memory usage.

I restarted the OSGi framework without bundle B then I found the below statistics

1972   422 root     S     214m  43%   0% java -jar osgi-3.10.0-v20140606-1445.jar -console

So after this I came to know that uninstalling of bundle B from OSGi was not updating the memory or CPU usage until I restart the OSGi framework.

so can someone suggest me, how can I clean the memory after uninstallation of bundles in OSGi.

Raj
  • 496
  • 7
  • 27
  • 1
    What did PlugIn B when you close it? How is your `stop`-Method? – TMichelsen Jul 29 '16 at 12:53
  • @TMichelsen I am performing some database operation in plugin B. when I stopped B, I close database connection and other resources as well. private void closeConnection() throws SQLException { if (sqlConnection == null || sqlConnection.isClosed()) { return; } sqlConnection.close(); sqlConnection = null; Runtime r=Runtime.getRuntime(); r.freeMemory(); r.gc(); } – Raj Jul 29 '16 at 12:57
  • sqlConnection = DriverManager.getConnection(ConfigurationConstants.DATABASE_NAME); this line is causing the high memory utilization. I am using sqlite database. – Raj Jul 29 '16 at 13:00
  • 1
    @Raj: Please do not place code into comments! Edit the question instead. Anyway I don't see the real memory usage in for question, only `VSZ` which something different AFAIK: [Virtual Memory Usage from Java under Linux, too much memory used](http://stackoverflow.com/questions/561245/virtual-memory-usage-from-java-under-linux-too-much-memory-used) – Robert Jul 29 '16 at 13:00
  • 1
    Try running jvisualvm (in bin directory of Java) and perform gc on the JVM. Java does not free memory if not necessary, even if the objects are cleaned up. You can see the real memory usage in JVisualVM after performing GC. The information that is shown by PS have no information about real Heap usage. – Balazs Zsoldos Jul 29 '16 at 14:03
  • See also similar questions: http://stackoverflow.com/questions/31988047/how-to-check-if-a-class-in-an-osgi-bundle-has-been-correctly-unloaded http://stackoverflow.com/questions/17170279/osgi-and-what-do-i-use-to-controll-loading-unloading-reloading-of-packages – Holly Cummins Aug 01 '16 at 10:01

1 Answers1

0

Uninstalling a bundle will prevent other bundles from wiring to it (class loader management), but it will not unload existing instances from memory or stop activity in those classes. To unload an instance, it's the normal Java garbage collection process; you need to ensure that nothing else in your application is holding a reference to the instance, and then the garbage collector will free resources used by the instance.

Holly Cummins
  • 10,767
  • 3
  • 23
  • 25
  • I have checked, I am setting all the references to null when bundle is stopped. – Raj Aug 02 '16 at 09:43
  • In that case your best bet is to take a heap dump and work out what's holding on to instances of the classes in the bundle. A tool like Eclipse Memory Analyzer is great for this. (It's references to instances of the classes loaded by that bundle you're worried about, not just references to the bundle object.) – Holly Cummins Aug 02 '16 at 21:20
  • Your JVM garbage collector may also choose not to shrink the heap size (what you see on the command line) even if occupancy is lower, for very sound CPU optimisation reasons. – Holly Cummins Aug 02 '16 at 21:21