Re: constant variables are not always placed in shared memory

[Owen Taylor <otaylor redhat com>]

On Tue, 2003-03-25 at 16:56, Stephane Chauveau wrote:
> Hi,
> 
> I was investigating the memory footprint of the gnome libraries
> when I realized that global constant variables initialized with
> an object address are implicitly made writable in order to be
> relocated. As a consequence, that are not placed into shared
> memory.
> 
> For example, a constant array of string addresses is
> not going to be shared as one could expect (the
> strings are constant and are placed in shared memory):
> 
> static const char * const my_strings[] = {
>   "hello", "world", "foo"
> }
> 
> It seems to me that some of the standard gnome libraries
> are declaring quite a lot of those pseudo-constant global
> variable. For example, libxml2 is allocating about 44ko
> of non-constant global data. Most of them are large constant
> arrays of strings like in my example. 
> Quite some memory could be saved by using numerical constants
> instead of addresses when that is possible.
> 
> For example: replace my_string[i] by my_string(i) 
> static const char str_char[] ="hello\0world\0foo\0" ;
>     static const char * const str_offset[] = {
>    0,   // offset of "hello"
>    6,   // offset of "world"
>    12   // offset of "foo"
> }
> 
> #define my_strings(i) (&str_char[str_offset[i]])
> 
> 
> Do you know if this is a know problem and if it is going
> to be addressed? 

It's a known issue to some of us. Optimizations of this
sort are already used for various bits of the Unicode
data in GLib. 

I doubt it will magically get fixed on it's own. While 
people are probably not going to take patches that 
do stuff like this for 3 element arrays of strings
(code maintainability is important too) if there are
cases where large numbers of relocations are being
made, it's worth submitting patches.

A somewhat intermediate approach in terms of maintainability
is:

static const char str_char[][6] = {
  "hello",
  "world"",
  "foo"
};

While it may waste a few bytes, it isn't nearly as error
prone as what you have above.

Regards,
                                          Owen