X Server: abused or buggy?

[Charles Lindsey]

On Tue, 09 Dec 2008 18:15:26 -0000, Óscar Fuentes <ofv at wanadoo.es> wrote:

> Glynn Clements <glynn at gclements.plus.com> writes:

>>> In other words, is a bug that under this usage mode the memory
>>> asigned to X grows monotonically?
>>
>> No. Most long-lived applications have memory "usage" which grows
>> monotonically, for the reasons outlined above. I put "usage" in quotes
>> because they won't necessarily be *using* the memory; they'll just
>> have it allocated (and swapped out).
>
> It is my impression that Okular's maintainers think that the X server is
> providing a service that their application is using. If this causes an
> steadily resource degradation, it's a bug on the service provider. IMO
> this point of view makes sense, if and only if using the X server for
> massively caching large pixmaps enters within the expected uses of the
> service. Even if this is considered abusing the X server, retaining
> large portions of memory after the serviced app closes reveals a poor
> QoI. Okular's maintainer expected that if heap fragmentantion could
> happen for resources stored on the X server, it should perform some sort
> of memory compaction for avoiding it. He architectured the app to
> exploit the X server caching feature and refuses to consider any other
> option, arguing that is the X server who needs to be fixed.
>
However, let us not dismiss this POV too soon. It is usually argued that  
an application that suffers from such memory fragmentation should be  
restarted occasionally (and, given that the Xserver runs in user space,  
unlike in Windoze, this is not impossible, though perhaps inconvenient in  
some circumstances).

HOWEVER, a compactor within the Xserver should, in principle, be possible,  
because large Pixmaps and the like are referenced by a serial number  
rather than by their address in (virtual) memory, and hence it should be  
possible to relocate them and simply alter the table that accesses them.  
That might need to be done in conjunction with a specially-written malloc  
for internal use within the Xserver, but specially-written mallocs are  
already in use in lots of other contexts.

Whether this would, could or should ever actually be done is a separate  
question, but for sure it should not be dismissed as "impossible".

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5