Opening on a sizeable program with debuginfo and source, and then attempting to step and run through it steadily increases the memory footprint of FryskGui. Starting at around 100M on x86_64 when the SourceWindow first opens, and increasing around .5M per step.
Created attachment 1519 [details] Screenshot of Gnome system monitor
Here are more observations on memory usage by the source window. These results were taken using "top" on a 2GHz P4 with 1GB of memory running FC5 with kernel 2.6.18-1.2257.fc5. Of particular interest were the memory readings provided by "top" for its Virtual, Resident and Shared columns. The scenario is this: I activated Frysk and took a measurement, then brought up the source window and took a measurement and then stepped the program 10 times taking two memory measurements after each step, with ~2 minutes between measurements. An interesting phenomena was observed which is the reason 2 measurements were taken between each step. It turns out there is a significance difference between the virtual memory measurment right after the "step" and the virtual memory measurement ~2 minutes after the step, which I suppose can be attributed to GC(garbage collection). The measurement taken immediately after the step was often 2-3 MB higher than the measurement taken ~2 minutes later for the same step. Here is a table of the measurements: Virtual Memory Resident Shared after ~2 min. later 137MB same 40 23 Initial startup of Frysk UI 139MB same 41 23 Showing debug process list 155MB 152MB 44 25 Activated source window 156MB 153MB 44 25 after 1 step 158MB 155MB 45 25 after 2 steps 160MB 157MB 45 25 after 3 steps 161MB 158MB 45 25 after 4 steps 163MB 160MB 45 25 after 5 steps 165MB 162MB 46 26 after 6 steps 167MB 164MB 46 26 after 7 steps 168MB 165MB 46 26 after 8 steps 170MB 167MB 47 26 after 9 steps 172MB 169MB 47 26 after 10 steps I also ran the test a different way by just doing 10 steps as quickly as I could. The initial virtual memory jumped to 192MB but fell back to 169MB within 2 minutes, the same as the memory measurement for step 10 above. Another phenomema I observed is that when the source window is exited, the memory measured the last time stays the same, it does not go away unless all of frysk is exited. On top of that, if another source window is activated with the same source code the memory useage jumps by another 4 MB over the last reading.
Created attachment 1541 [details] finalize() log file A quick initial assessment shows that StackFrame.java, FrameCursor.java, and the private class UnwindArgs in StackTraceCreator.java never seem to get collected, while other objects associated with stepping do. The attached file is a log of finalize() calls from a variety of classes, some from the DOM, Dwfl and DwflLine. StackFrame is a pure Java file, FrameCursor and UnwindArgs have native bindings; the DOM classes are pure Java and the Dwfl classes have native bindings. Failure to reach the finalize() for UnwindArgs means that native clean-up functions like unw_destroy_addr_space are not called.
Looks like the TreeStore in CurrentStackView does not release any of the stored StackFrame objects contained in its rows after a call to TreeStore.clear(). Working up a standalone test for upstream java-gnome.
Upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=407591
Well the story is that each time a step is performed, the stack trace gets re- generated and the TreeView storing the stack trace in the source window needs to be refreshed with new StackFrame objects. Due to the JG bug mentioned above, each time the tree is refreshed and (supposedly) cleared, the Java objects contained within are not marked for collection and get lost. This is a serious problem since StackFrame objects are relatively heavy objects, with several heavy fields, such as DOMSource. Nullifying references to all StackFrame fields each time the stack trace is rebuilt is a temporary workaround, but the problem really needs fixing in Java- Gnome. Suspending this bug until a fix for #4042 is created.
Re: #4042, I've tested the patches Sami has made and they fix the problem.