This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Extending /proc/*/maps


On 12/05/2011 2:42 PM, Corinna Vinschen wrote:
On May 12 13:53, Ryan Johnson wrote:
On 12/05/2011 12:55 PM, Corinna Vinschen wrote:
heap *heaps;
This is a misnomer now -- it's really a list of heap regions/blocks.
I don't think so.  The loop stores only the blocks which constitute
the original VirtualAlloc'ed memory regions.  They are not the real
heap blocks returned by Heap32First/Heap32Next.  These are filtered
out by checking for flags&   2 (**).
Sorry, I cut too much context out of the diff. That's
heap_info::heaps, which indeed refers to heap regions which we
identified by checking flags&2 (that's why it needs the heap_id
inside it now, where it didn't before) (++)
So you think something like heap_chunks is better?
Maybe. I actually only noticed because the code snippet you originally sent also used 'heaps' as an identifier and the two clashed when I pasted it in ;)

+		heap *h = (heap *) cmalloc (HEAP_FHANDLER, sizeof (heap));
+		*h = (heap) {heaps, hcnt, barray[bcnt].Address,
+			     barray[bcnt].Address + barray[bcnt].Size,
+			     harray->Heaps[hcnt].Flags};
+		heaps = h;
Given that the number of heap blocks is potentially large, I think
Not really.  See (**).  3 heaps ->   3 blocks, or only slightly more
if a growable heap got expanded.
See (++). When I point my essentially-identical version of the code
at emacs, it reports 8 heaps, each with 2-4 regions. The list
traversed by fill_on_match has ~20 entries.
Oh, ok.  From my POV 20 is not a large number.  Ordering might take
more time than scanning.  I don't think it's worth the effort.
You might be right. I just threw my test case at Firefox, and even that memory hog generates < 50 entries. I guess it does some sort of manual memory management as well, because windbg reports waaaay more allocated address space regions than that...

Besides, you've shown that we potentially need each heap block multiple times, so delete-after-use isn't a good idea.

Ryan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]