[pypy-dev] pypy GC on large objects Re: funding/popularity?
renesd at gmail.com
Thu Dec 23 14:33:50 CET 2010
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
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.
On Thu, Dec 23, 2010 at 11:14 AM, Armin Rigo <arigo at tunes.org> wrote:
> Hi Dima,
> On Wed, Dec 22, 2010 at 11:21 PM, Dima Tisnek <dimaqq at gmail.com> wrote:
>> --- Comment #4 from Boris Zbarsky (:bz) <bzbarsky at mit.edu> 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,
> pypy-dev at codespeak.net
More information about the Pypy-dev