Date: Thu, 15 Jan 1998 13:08:20 -0600 (CST) From: Joel Ray Holveck <joelh@gnu.org> To: atrens@nortel.ca Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: sharable static arrays? Message-ID: <199801151908.NAA01914@detlev.UUCP> In-Reply-To: <199801151828.NAA14659@mescaline.gnu.org> (atrens@nortel.ca) References: <199801151828.NAA14659@mescaline.gnu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Copy-on-write aka `lazy copy' is a detail of the implementation
> *not* the interface. You must assume that each process gets its own
> data segment, period. Otherwise you couple your code to the OS
> implementation. There are a number of reasons why this a bad idea.
I realize that I can't depend on details of the OS implementation,
particularly since copy-on-write is transparent to the user. However,
when I'm writing a program and trying to decide whether a large lookup
table should be built statically into the compiled code, generated at
runtime, or whatever, it is helpful to know how the memory usage will
be affected. That's what I'm trying to accomplish with this whole
issue.
> Interestingly, in the following example, strategy 'a' uses *double* the
> memory of strategy 'b':
> strategy a:
> int foobared[] = { 3, 3, 3, 3, 3 };
> int foobared[5] = { 3, 3, 3, 3, 3 };
> strategy b:
> const int foobared[] = { 3, 3, 3, 3, 3 };
> const int foobared[5] = { 3, 3, 3, 3, 3 };
> When you tell me why, you have probably answered your own question. ;)
Hmmmm.... Either way, it's illegal to define 'foobared' twice.
If you meant two use different identifiers, and were global variables,
then one could consider an optimizing compiler which recognizes that
the two arrays under strategy `b' are identical and use one instance
of them, with both arrays pointing to the same place. Initial
investigations indicate that gcc does not do this with arrays of ints
(although it does with strings in certain optimization modes). Note
that the object files produced by the two situations, without
optimization, each contain two copies of the array. (Yes, I tried
it.) Depending on what is done by optimization effects is and
implementation detail and should not be considered. :-) But in case
you're interested (I was), each situation, when compiled to an
executable with -O3 optimization, has separate copies for each array
(as verified by both nm and gdb). In the const case, they are in the
text segment, and in the non-const case, they are in the data segment.
(This answers my original question, thank you.) However, without the
aforemention hypothetical optimizer, I cannot reason why the situation
a used twice as much memory.
If these were auto variables, then strategy a would require both stack
space for the array at runtime, and text space for the initial value
in the executable, whereas strategy b should only require one copy of
its space in either text or data, I still haven't determined which.
(This is still based on the assumption that it is an error to modify a
const variable through another identifier.)
Happy hacking,
joelh
--
Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan
Fourth law of programming:
Anything that can go wrong wi
sendmail: segmentation violation - core dumped
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801151908.NAA01914>