[gclist] 64 bit machines and conservatism

[Eliot & Linda]

Hans Boehm wrote:
> 
> 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.

The Smalltalk community went thoguh the 16-bit to 32-bit switch when
Smalltalk-80 (then 16-bits) emerged from Parc.  The experience most of
us had was that the image grew by 50%.  This is because
a) string data doesn't change size
b) the larger pointer space allows new optimizations

This is even more true of a 64-bit world.  So my wild guess would be
that a 64-bit Smalltalk image would be only 30% larger than an
equivalent 32-bit one if the implementation took advantage of the new
representational possibilities.
_______________,,,^..^,,,_______________
Eliot