[gclist] 64 bit machines and conservatism

[Hans Boehm]

On Dec 15,  1:51pm, Marc Feeley wrote:
> However it is unrealistic to double the space requirements of an
> application unless there is a really really compelling reason to do so
> (i.e. more than "look... by dereferencing this pointer I can change
> the settings on my grandma's toaster!").  A more practical approach is
> to somehow segragate 32 bit pointers (local stuff) and 64 bit pointers
> (possibly remote stuff) so that 64 bit pointers only show up in a few
> places.  I bet that for most applications the 32 bit pointers
> will far outnumber the 64 bit pointers.
>
The tradeoffs here actually seem fairly complex to me.  Different vendors seem
to handle them differently.  There's a lot to be said for a unique pointer
size. You only need one set of libraries, and you don't get the win16/DOS
near/far pointer mess.

There are also some situations in which 32-bit local addresses are not enough.
 My impression is that database benchmarks are routinely run on machines with >
4GB primary memory.  I suspect a reasonable number of numerical problems also
fall into this category.  At $10/MB, 4GB is $40K, which is not at all
unreasonable for a large application.  And for PC-style memory, the price is
much less than that.  (Of course you can't put 4GB in the average PC, yet.)  If
you want to use a single set of libraries and development tools and you want to
target such applications, then local pointers should be longer than 32 bits.

I still suspect that anything near a 4GB garbage collected heap is rare.  But
that may not be the only thing you want to address.

Hans



-- 
Hans-Juergen Boehm
boehm@mti.sgi.com