bug#56546: 29.0.50; unbounded RAM comsumption when displaying images

[Jose A. Ortega Ruiz]

On Thu, Jul 14 2022, Lars Ingebrigtsen wrote:

> "Jose A. Ortega Ruiz" <mail@jao.io> writes:
>
>>   - emacs -Q
>>   - M-x eww RET https://xenodium.com/emacs-zones-to-lift-you-up/
>>   - RAM consumption grows to ~600Mb
>>   - R (redisplay page): RAM grows to ~1100Mb
>>   - R (redisplay page): RAM grows to ~1752Mb
>>   - R (redisplay page): RAM grows to ~2222Mb
>>   - rinse and repeat: RAM never goes down
>>   - (image-cache-size) reports a modest 82Mb
>>   - Kill buffer:  high RAM consumption is still at its maximum, even
>>     after (image-cache-size) goes to 0
>
> I think this should all be fixed on the current trunk now -- can you
> check?

Yes, it essentially does.  Only the first jump to ~630Mb happens, and
then memory stays there after repeated reloads.  If i do it often (or
quickly, i think) enough i can make it occasionally jump to the ~1200Mb
mark, but for instance cleaning the image cache makes it go back to
~600Mb (so there are clearly situations where big chunks of memory do
get released back to the system, thankfully).

So i think you did fix the problem, thanks a lot Lars!  

While we're here, i was inspecting the image-cache-size during the
reloads of the page, and i saw every reload increases that size by about
30Mb (then it will eventually go down as old images are
released)... given that, the big initial jump of ~500Mb in RAM
consumption surprises me a little, but i see reasons why it can be
completely normal for some initial allocation (and how it might be
staying there because of libgcc policies).  I was also naively expecting
that, given that i'm reloading the same page with the "same" images,
they'd be found in the cache the second and subsequent times, but, since
the cache size increases, i see that they're not considered the "same"
by the caching mechanism; i can again see reasons for that behaviour (i
am sure the cache is not judging image equality using "image urls"),
just mentioning it in case it's unexpected or there's an easy way of
reusing the cached images).

Anyway, thanks a lot for bearing with me and solving the problem: this
bug is all but fixed now from my point of view.

Cheers,
jao
-- 
That's a high price to pay for a theoretically inelegant misfeature
that's seldom used correctly in portable code.
  -Will Clinger, r6rs-discuss mailing list