[TAVERNA-256] OutOfMemoryException on multiple Replace Nested Workflows / Import

• Type: Bug
• Status: To Do
• Priority: Major
• Resolution: Unresolved
• Component/s: Taverna Workbench
• Labels: memory

Environment

: stain@ralph ~;lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 11.10
Release: 11.10
Codename: oneiric


: stain@ralph ~;java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

Taverna Workbench 2.3.0

• Assignee: Unassigned
• Reporter: Stian Soiland-Reyes
• Created: 16/Jan/12 13:30
• Updated: 28/Apr/15 11:41

Description

The "Replace nested workflows" dialogue seems to consume 13 MB or more for every time the dialogue is brought up, when the workflow that is being edited has multiple nested workflows. The memory does not seem to be freed, and is held by Batik SVG for the diagram preview in the dialogue.

See attached workflow.

Some workflows experience even higher consumption, for instance http://www.myexperiment.org/workflows/2653

To reproduce:

Open the attached workflow. Right click on one nested workflow and select "Edit nested workflow". Do a minor change, such as adding or removing a string constant. Click Save. Now go back to the main workflow, and for each of the other nested workflows, right-click and select "Replace workflow" - when the dialogue appears, select the last open and the dropdown list to find the already open nested workflow.

Measure in jProfiler memory usage and allocation hotspots - with a GC reset and memory allocation off/on again after the first replacement. (To ignore initialisation costs). Finally do a double GC reset again, and check out Memory -> Allocation tree - select only Live objects.

Numbers mentioned here are for 64-bit Java 6 on Ubuntu Linux.

Now every replaced nested workflow seem to have increase these numbers and the total memory used by the VM - see screenshot.

Suggested short-term fix is to remove the diagram preview and the preview-loading-thread from the Import/Replace dialogue.

Note that there is no increase in threads that are Alive afterwards, so the increase memory must be kept by a static or one of the existing SVG threads.

Alan says that opening and closing workflows does not have a similar problem. Stian remembers that in that code there is something that explicitly clears up some SVG stuff onDispose() - do we need a similar thing in the import dialogue?