[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] const / static (against current CVS)
From: |
Andreas Mohr |
Subject: |
Re: [Qemu-devel] [PATCH] const / static (against current CVS) |
Date: |
Wed, 24 Aug 2005 16:38:51 +0200 |
User-agent: |
Mutt/1.4.2.1i |
Hi,
On Wed, Aug 24, 2005 at 02:41:44PM +0100, Paul Brook wrote:
> > Probably more important is to make sure none constant data structures
> > are done on the stack. There is no good reason why any code page
> > should be read-write.
>
> Huh? this is nonsense.
Uhoh, I seem to have managed to stir up a veritable hornet's net with my
patch...
> Making global data readonly is a small win because it means it can be shared
> by multiple instances of the same application.
Yup.
> Moving global RW data onto the stack isn't neccly a win. Most systems have a
> relatively small limit on stack size, so putting large objects on the stack
> is a bad idea.
Indeed. Witness e.g. Linux's optional kernel stack reduction to 4k
and the problems that ensued.
> Contrary to popular belief the "const" qualifier on pointers has absolutely
> no
> effect on optimization. It's simply a debugging aid so the compiler will
> generate an error if you accidentally assign to it. It's perfectly legal to
> cast a (const char *) to a (char *) then dereference and write to it,
> provided the object the object it points to is modifiable.
I was thinking just that: that constifying stuff at most gives a very small
compiler gain, but most probably just nothing (some people reported some
rather weak 1.4% performance gain somewhere!? Statistical noise...).
Since you say it's nothing I'm strongly inclined to believe it...
Well, it's not only a compiler debugging aid, but also a runtime debugging
aid, since random (attempted) .rodata page corruption should SEGV in that case.
Andreas Mohr