Darryl Miles writes: > Andrew Haley wrote: > > This doesn't sound very different from the small memory model. With > > the small model, the program and its symbols must be linked in the > > lower 2 GB of the address space, but pointers are still 64 bits. This > > is the default model for gcc on GNU/Linux. It would be possible in > > theory to have a `smaller' memory model that only allowed 32-bit > > pointers, I suppose. > > Small memory model ? I don't understand the point of the "small memory > model" nor can I substantiate anything you are saying from the > littlepickcloud, LOL what a domain. > > 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. > > This is amazing! There is no way that going from the ia32 to > > (presumably) the x86_64 small model should more than double > > memory consumption. Where has all that memory gone? I think > > some analysis of memory consumption is needed. > > 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. Andrew.
