[Vm-dev] Large 64-bit object memory (was: VM Maker: VMMaker.oscog-eem.281.mcz)

[David T. Lewis]

On Sat, Apr 06, 2013 at 09:30:11PM -0400, David T. Lewis wrote:
>  
> On Sat, Apr 06, 2013 at 05:15:43PM -0700, Eliot Miranda wrote:
> >  
> > On Thu, Apr 4, 2013 at 5:19 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> > 
> > >
> > > On Thu, Apr 04, 2013 at 01:25:10PM -0700, Eliot Miranda wrote:
> > > >
> > > > On Thu, Apr 4, 2013 at 3:17 AM, Nicolas Cellier <
> > > > nicolas.cellier.aka.nice at gmail.com> wrote:
> > > >
> > > > >
> > > > > Yes, I always wanted to ask what oops signed-ness was good for?
> > > > > IMO, they could simply be declared usqInt.
> > > > >
> > > >
> > > > +10 raisedTo: SmallInteger maxVal.  But the milk is already spilt :)
> > > >
> > > > I'm glad you said that.  I'm reminded of House of Cards.  "You might
> > > think
> > > > so but I couldn't possibly comment." ;)
> > > >
> > > > It might be worth-while trying to make this change and fixing the very
> > > few
> > > > places where signedness is important (the SmalInteger arithmetic
> > > > primitives).
> > > >
> > >
> > > IMO an object pointer should be declared sqOop to clearly distinguish
> > > it from some something that is intended to be used as an integer.
> > 
> > 
> > OK, but is sqOop a void pointer or what?  void pointers are ok except that
> > they have to be cast all the time.  char * is poor; too easily confused
> > with other pointers.  sqObj * (where sqObj is some opaque struct) is good.
> >  Integral types are easy to deal with.  But signedness is the major thing
> > to avoid.  SO either unsigned or pointer.  But which?
> > 
> 
> You are missing my point. If someone is going to go to the trouble of
> properly declaring object pointers, then they may as well use an intention
> revealing type declaration.
> 
> In principle there is no reason that an object pointer should not refer to
> the primary key in a relational database table (to pick an intentionally
> rediculous example). But an object pointer is an object pointer, it is
> not an integer and it is not a C pointer.
> 
> In practice, the current use of sqInt to represent object pointers is
> confusing, but is not a big problem. After all, object memories of over
> 7 GB work fine with the 64-bit object format (limited by physical memory
> on my PC as far as I can tell). Although I note with dismay that there
> seems to be yet another regression here, so I'll need to hunt that down
> once more :-/

OK, no regression after all, just a few type definitions required in the
unix platforms sources (attached, along with SystemReporter stats that show
the memory usage).

With an up-to-date Squeak trunk image traced to 64-bit object format
(from http://build.squeak.org/job/Squeak%2064-bit%20image/), and running
on a Linux PC with 8GB memory, I can allocate large strings until the
system bogs down with swapping at an image size of about 7GB. I can also
successfully allocate e.g. a 6GB String or ByteArray, although indexing
into the array fails due to issues unrelated to object pointer addressing.

Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: unix-large-memory-64.tgz
Type: application/x-gtar
Size: 16209 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130414/53330f2d/unix-large-memory-64-0001.tgz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SystemReporterBig64.png
Type: image/png
Size: 68972 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130414/53330f2d/SystemReporterBig64-0001.png