Hi Abhijeet, On Fri 30 Jul 2010 02:38, Abhijeet More <abhijeet.m...@gmail.com> writes:
> To debug this further are there any useful places in the > stream-for-each implementation that I could do a gc-stats from? Or > would we need to look at the C implementation? > > Can anyone suggest good starting points for this? We started poking this a little at the GNU Hackers Meeting last weekend. I say "we" but it was really Tibi (copied on the mail) who was doing most of the work. We printed out the object-address of the stream at the start of the iteration, then ctrl-C'd in GDB somewhere in the middle. We then called GC_print_heap_obj on that address and it printed as a two-word object. We scm_display'd the address, and it was not a stream. (It was used for something else.) So, it's not the case that the beginning of the stream was being held on to. Which is a bad thing -- it means that somehow something in the middle was being held on to. To really track this down we need a heap profiler. To make a heap profiler, we need to hack libgc. libgc has some of the things we need already, but some are only present in debug builds, which is ridiculous -- one should always have the ability to profile the heap. We need to figure out which value is being misidentified as a pointer to a heap-allocated stream-pair. That is my analysis anyway. The next step is to be able to expose the back-pointer graph from libgc, and write analysis tools to figure out which non-stream objects point to a stream. Andy -- http://wingolog.org/
