Hi David,

On Thu, Dec 4, 2014 at 5:12 PM, David T. Lewis <lewis at mail.msen.com> wrote:

> On Thu, Dec 04, 2014 at 06:50:05PM -0500, Chris Cunnington wrote:
> >
> > And it's still pretty confusing. The fact that it can confuse Levente
> Uzonyi
> >is both liberating and a salutary lesson. And as I've opened my big mouth,
> > I may as well put my head on the chopping block.
> >
>
> I find it very confusing also. After all, we are dealing with address space
> in memory, virtual address space in the OS process that maps to that
> memory,
> a big array of object memory that got allocated somewhere within that
> process
> virtual address space, a system of byte-addressable object pointers that
> refer
> to locations within the object memory, and a bit of tricky object pointer
> decoding that involves checking each pointer value to see if it points at a
> 4 or 8 byte boundary, and if not, then decode the pointer as an immediate
> value.
> And of course, the thing that that object pointer points to is an object
> header
> word, which might be either 32-bits or 64-bits, and which might be one of
> up to three header words, unless is it Spur, in which case it always has
> one
> header word.
>

Forgive the correction but in Spur an object has a 128-bit/16 byte header
if it has more than 254 slots.  There's only room for an 8-bit slot count
in the 64-bit header, so when an object's size overflows it overflows into
a full 8-byte slot size field which precedes the normal header.  This turns
out to be a good choice because a) using a slot count gives 4 or 8 times
the range than using a byte size (as the V3 object representation does),
and b) the overhead of the extra 8 byte header is always less than 0.8% in
32 bits and less than 0.4% in 64-bits.  See slides 9, 29 from my talk at
ESUG:
http://www.slidesearch.org/slide/spur-a-new-object-representation-for-cog.

Also note that in Spur the object memory need not be contiguous.  See slide
32.  It grows by adding dis-contiguous segments, the only requirement being
that these are at a higher address than the first segment allocated, a
straight-forward constraint to observe in practice.

You are entitled to be confused. If you were not confused the first few
> times you looked at this, you probably were not paying attention.
>
>
> > - the heap readdresses 32-bit locations, so they are not the same as the
> addresses in memory, the numbers on the metal
> > - a 32-bit address can be an immediate object, because the address can
> be a 30-bit number. (i.e. @00000007)
> > - a 32-bit address can be a reference to 96-bit object somewhere. The
> 32-bit address leads to a header that describes the object pursuant of the
> ObjectMemory comment [1]
> >
> > If these things are true, then doesn't that mean every time a number is
> used, then that 32-bit space, which could have been an address, is now
> invalid as an address to an object? If that's right, then it's a tad odd,
> right? The more math you do then the more @00000007 and @00000008 numbers
> are consumed leaving fewer, of the possible 4.3 billion 32-bit words to
> address objects with headers. And if that's true, then some intelligence in
> the VM somewhere is saying: "No, that address is working as an 'immediate
> object' for math. You'll have to use another 32-bit address to lead you to
> the 96-bits that come complete with a header".
> >
>
> You are exactly right. The address space is "wasteful". The object
> pointers are
> pointers to byte locations within the object memory space. But the
> positions in
> the object memory are either 32-bit words (in the current object memory)
> or 64-bit
> words (in the Squeak "format 68002" object memory or in 64 bit Spur).
>
> So it is indeed wasteful to use byte-addressable pointers to point to
> 32-bit or
> 64-bit locations in the object memory. But there is a hidden advantage to
> this
> waste of address space. Any object pointer that points to a byte that is
> not
> on a 32-bit (or 64-bit) boundary is pointing at something that cannot
> possibly be an object header. In a 32-bit object memory, only one of every
> four addresses can be a valid location in the object memory. All the rest
> of
> those "wasted" addresses can be used for something else.
>
> So what should the wasted addresses be used for? Immediate objects.
>

Well, Chris may be pointing out that there are no pointers into the middle
of objects, and that this pointer space is somehow "wasted".  But given
that the garbage collector moves objects around, any wasted 4-byte or
8-byte aligned addresses not being used to point to objects at one time may
be used at another.  In practice the OS's layout of memory (e.g. only 50%
of the 32-bit address space is available by default on Windows XP or 75% of
the address space on linux) is more of a limitation.

With 64-bits things change.  x86-64 implementations currently only sup[port
56-bit physical addresses.  That's a lot of space address space.  WIth
64-bit processors one can say that address space is cheap.



> Dave
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141204/88e949a1/attachment.htm