Re: [Gems-users] Memory leak?

[Mike Marty <mikem@xxxxxxxxxxx>]

Good point, Milo.  I hadn't thought of this and it must account for
growing memory usage.

The code to allocate the ENTRY on demand is in DirectoryMemory.C:144

It seems that all instantiations of DirectoryMemory could periodically
sweep the data structure and deallocate any block that is in the default
state (say Directory_State_I)??

--Mike


> 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
>
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>