Ruby uses an internal sparse representation of the memory that is
lazily allocated when a memory locations is first accessed. Even if
Ruby is set not to track the actual data values, it still tracks any
per-block state in memory (such as directory state). Once a memory
location is touched, Ruby will never deallocate the memory it
allocated. If data values are not being tracked, one could modify
Ruby to deallocate memory of blocks in a particular state, but doing
so would be non-trivial in my opinion.
- Milo
On Feb 1, 2006, at 6:19 PM, Dan Gibson wrote:
There is the issue of how Simics represents the target's memory image.
Try running the same simulation without Ruby or Opal, and see if
you see
a similar growth in size. It could be that as the simulation
progresses,
Simics is holding more and more of the target's memory image in the
host's physical memory.
Regards,
Dan
Nauman Rafique wrote:
The stats in the profiler was the first thing that come to my mind
too.
But we are talking hundreds of mega-bytes here. I do not think our
poor little
histograms are that ugly.
Thanks.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
--
Milo M. K. Martin (milom@xxxxxxxxxxxxx)
http://www.cis.upenn.edu/~milom/
Assistant Professor
Computer and Information Sciences Department
University of Pennsylvania
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}