Hello, I think this is a case where the object returned by ctypes.create_string_buffer() could use a correct __sizeof__ method return value. If pypy supported that, then the GC's could support extensions, and 'opaque' data structures in C too a little more nicely.
I think ctypes was started before __sizeof__ became available... so it seems many of it's methods are not updated yet. __sizeof__ is not mandatory, so many extensions have not been updated to support it yet. cheers, On Thu, Dec 23, 2010 at 11:14 AM, Armin Rigo <[email protected]> wrote: > Hi Dima, > > On Wed, Dec 22, 2010 at 11:21 PM, Dima Tisnek <[email protected]> wrote: >> --- Comment #4 from Boris Zbarsky (:bz) <[email protected]> 2010-12-22 >> 13:43:23 PST --- >> So what I see this page do, in horizontal mode, is create 17 canvases each of >> which is width="816" height="3587". That means that each of them has a >> backing >> store of 816*3587*4 = 11,707,968 bytes. So that's about 200MB of memory >> usage >> right there. >> >> I have no idea why they feel a need for 17 huge canvases, but if they want >> them, that's how much memory they'll take... > > That looks very similar to an issue with PyPy's own GC, in which > ctypes.create_string_buffer() returns objects which tend to be GC'ed > late. That's because the string buffer object in ctypes appears (to > PyPy's GC) to be just a small object, even though it actually > references a potentially large piece of raw memory. Similarly, my > vague guess about the above is that the 17*11MB of memory are hold by > 17 small objects which firefox's GC think don't need to be collected > particularly aggressively. > > > A bientôt, > > Armin. > _______________________________________________ > [email protected] > http://codespeak.net/mailman/listinfo/pypy-dev > _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
