Memory leak due to unreferenced Objects created via 1.3.1 ActiveX bridge

Objects created via 1.3.1 ActiveX bridge will not be dereferenced and so SAP has found a serious memory leak in an application (programmed in Visual Basic), which uses the Internet Pricing and Configurator (IPC server) (programmed in Java). As communication layer between VB and Java, the Sun ActiveX bridge (Jsdk 1.3.1) is used

In order to narrow the problem down, SAP created a small test application. It consists of a VB programm (VBBeansTestSmall.exe), which interacts with two Java-Beans (MyCalculatorBean and MyResultBean) via Sun ActiveX bridge.

The OS Version the customer uses now is win2003.
However, SAP build the test application on WinXP SP1.
SAP would suggest setting up the test application on a WinXP.

SAP uses WinXP SP1 and JDK 1.3.1 SP12.
But they also found the ,,problem with other Service Packs of JDK 1.3.1. (in testcase 1.3.1_16 is used)
Since Sun made incompatible changes at the ActiveX-Bridge in JDK 1.4.2 and SAP didn't port application to JDK 1.4.2, SAP instruct the customers to use jdk 1.3.1.
                                                                               
The real application, where SAP found the memory leak problem is build with Visual Basic 6.
The test application was compiled with VB.Net 2003.
There, the same problem occured.
So this seems to be independent to the VB Version

They face the problem that still have Objects in the Java VM, which should not be there anymore, because they are not referenced by Visual
basic anymore. These objects are not garbage collected because they are still referenced by the object sun.beans.ole.JavaObjectInterface
(described in attached document: "screenshots of memory profiler").
                                                                               
The questions from SAP are:
a. Why are they still referenced?
b. How can we get rid of these references so that our objects are garbage collected?
                                                                               
Note: In the real application, the wrongly referenced beans have several Megabytes. This is a serious memory leak.

Testcase
-----------
- The complete testcase is provide in 2 zip files (VBBeansTestSmall.zip,beans.zip) and detailed profiler results (using YourKit Java Profiler) shown in memory_profiler.doc
- install jdk1.3.1_16
- copy the beans.zip contents in C:\Sources\Workspaces\TestProjects\JavaBeansTest\output as described in MyCalculatorBean.reg and MyResultBean.reg , so there is no need for manual/packager changes
If the beans cannot be copied in that directory that adapt the paths in the two *.reg files to your system settings:
a) Adapt the path to your jdk.
b) Adapt the path to the jar file in which the beans are.
You can do this by hand (text editor) or via the Sun ActiveX Packager described in the tutorial (http://java.sun.com/products/plugin/1.3/docs/script.html).

- register the *.reg files at the registry by simply double clicking them

- cd <your dir>\VBBeansTestSmall\bin\
- run VBBeansTestSmall.exe (below customer instructions)

If you start the exe file you get a window with three buttons.
1. With button "new MyCalculatorBean" you create a new MyCalculatorBean, which is stored in a member variable on VB side.

2. Using button "getMyResultBean" you can create a new MyResultBean. For this, the method getMyResultBean from MyCalculatorBean is called, which returns a new instance from MyResultBean. The reference to the returning bean is stored in a local variable, which is set to "Nothing" immediately after the call again, so that we would expect that the MyResultBean instance is removed from memory at Java side again.

3. The button close "close MyCalculatorBean" sets the member variable, which holds the reference to the MyCalculatorBean instance, to "Nothing". We would expect that the MyCalculatorBean instance is removed from memory at Java side now.

Unfortunately, the beans, which were created via ActiveX bridge, remain in the Java VM memory even their references were deleted on VB side. Using a Java memory profiler, you can see that Objects from type sun.beans.ole.JavaObjectInterface are still referencing the Bean objects. It follows that they can't be garbage collected, which causes somehow the memory leak, since the bean objects in our real application can have size of several MB.

Some screenshots from a memory profiler at different states of the application are shown in memory_profiler.doc


###@###.### 2005-06-24 13:46:41 GMT
###@###.### 2005-06-29 12:07:50 GMT