[pypy-dev] pypy GC on large objects Re: funding/popularity?

[René Dudfield]

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 <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,
>
> Armin.
> _______________________________________________
> pypy-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/pypy-dev
>