This is the mail archive of the
mailing list for the GCC project.
Re: Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?
Andrew Haley wrote:
Darryl Miles writes:
> Andrew Haley wrote:
> I'm not aware of a small memory model until now, let alone that I maybe
> actually using it already and that its already what I'm making an
> inquiry about.
Reading the gcc documentation would help you here. Section 3.17.13,
Intel 386 and AMD x86-64 Options.
Its just a shame that section number related to a different CPU
depending upon which version of GCCs documentation you are looking at.
Ah found it for those following:
I think the main point I was getting at was this ABI would run within a
32bit address space at runtime (just like 32bit code does). It would be
possible for it to see and use the 64bit version of kernel calls
however, even if the values for stuff like mmap() always returned within
the bottom 4Gb address space.
The purpose of the new ABI was to make use of AMD64/EMT64 features
knowing there is a runtime guarantee they are available. This would
untimely end up with an entire distribution being recompiled for this
ABI to see the speed benefits (if there are any to be had?).
> I presume all the memory is eaten up dealing with 64bit issues both
> Mozilla (using XPCom) and Eclipse (running in a Java JVM) make
> extensive use of pointers. Although Mozilla is a little harder for
> me to measure comparatively but I've never gotten it over 1Gb
> Resident Set Size (with no swap in use).
That's interesting. I certainly have seen some increase in memory
consumption goinf from 32-bit to 64-bit applications on x86_64, but
the fact that in your case it more than doubles is come cause for
concern. Even if pointers were 50% of the allocated memory pool,
which is a pretty extreme assumption, that would only increase memory
use by 50%. In your case, however, memory use has increased by 150%.
This needs explanation.
There is a possibly of extra padding alignment issues (so there maybe
benefits within these applications to reordering stuff to account for
64bit alignment rules).
There is increased stack size needs and increased stack usage in both
these apps which make use of many threads.
I'm not sure if mmap() files that are also paged in the RSS count, as I
guess in the 32bit runtime model the strategy for using mmap() to access
files maybe different to 64bit. For example I had to increase the open
fd limit on Eclipse to 2048 since I could easily make it break the
default 1024 limit from doing a complete workspace rebuild. Most of
these open files are due to mmap()s.
Maybe there are other reasons I can't think of right now.
Thats a job for someone, ensure enough information is emitted in the -g3
debug information going into the executable to reconstruct all
structures/datatypes so that a tool could extract the amount of wasted
padding and calculate the potential for savings to be made through
reordering structure members and the like.