Plans for Linux ELF "i686+" ABI ? Like SPARC V8+ ?

[Darryl Miles]

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:

http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options


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.


Darryl