public inbox for frysk-bugzilla@sourceware.org
help / color / mirror / Atom feed
From: "rmoseley at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: frysk-bugzilla@sourceware.org
Subject: [Bug general/3915] Memory leakage
Date: Fri, 02 Feb 2007 21:35:00 -0000 [thread overview]
Message-ID: <20070202213454.6613.qmail@sourceware.org> (raw)
In-Reply-To: <20070124155300.3915.mcvet@redhat.com>
------- Additional Comments From rmoseley at redhat dot com 2007-02-02 21:34 -------
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.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3915
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
next prev parent reply other threads:[~2007-02-02 21:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-24 15:53 [Bug general/3915] New: " mcvet at redhat dot com
2007-01-24 15:53 ` [Bug general/3915] " mcvet at redhat dot com
2007-02-02 21:35 ` rmoseley at redhat dot com [this message]
2007-02-07 14:48 ` mcvet at redhat dot com
2007-02-08 20:41 ` mcvet at redhat dot com
2007-02-14 17:45 ` mcvet at redhat dot com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070202213454.6613.qmail@sourceware.org \
--to=sourceware-bugzilla@sourceware.org \
--cc=frysk-bugzilla@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).