<div dir="ltr">Hi David,<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 4, 2014 at 5:12 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Thu, Dec 04, 2014 at 06:50:05PM -0500, Chris Cunnington wrote:<br>
><br>
> And it's still pretty confusing. The fact that it can confuse Levente Uzonyi<br>
>is both liberating and a salutary lesson. And as I've opened my big mouth,<br>
> I may as well put my head on the chopping block.<br>
><br>
<br>
</span>I find it very confusing also. After all, we are dealing with address space<br>
in memory, virtual address space in the OS process that maps to that memory,<br>
a big array of object memory that got allocated somewhere within that process<br>
virtual address space, a system of byte-addressable object pointers that refer<br>
to locations within the object memory, and a bit of tricky object pointer<br>
decoding that involves checking each pointer value to see if it points at a<br>
4 or 8 byte boundary, and if not, then decode the pointer as an immediate value.<br>
And of course, the thing that that object pointer points to is an object header<br>
word, which might be either 32-bits or 64-bits, and which might be one of<br>
up to three header words, unless is it Spur, in which case it always has one<br>
header word.<br></blockquote><div><br></div><div>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: <a href="http://www.slidesearch.org/slide/spur-a-new-object-representation-for-cog">http://www.slidesearch.org/slide/spur-a-new-object-representation-for-cog</a>.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">You are entitled to be confused. If you were not confused the first few<br>
times you looked at this, you probably were not paying attention.<br>
<span class=""><br>
<br>
> - the heap readdresses 32-bit locations, so they are not the same as the addresses in memory, the numbers on the metal<br>
> - a 32-bit address can be an immediate object, because the address can be a 30-bit number. (i.e. @00000007)<br>
> - 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]<br>
><br>
> 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".<br>
><br>
<br>
</span>You are exactly right. The address space is "wasteful". The object pointers are<br>
pointers to byte locations within the object memory space. But the positions in<br>
the object memory are either 32-bit words (in the current object memory) or 64-bit<br>
words (in the Squeak "format 68002" object memory or in 64 bit Spur).<br>
<br>
So it is indeed wasteful to use byte-addressable pointers to point to 32-bit or<br>
64-bit locations in the object memory. But there is a hidden advantage to this<br>
waste of address space. Any object pointer that points to a byte that is not<br>
on a 32-bit (or 64-bit) boundary is pointing at something that cannot<br>
possibly be an object header. In a 32-bit object memory, only one of every<br>
four addresses can be a valid location in the object memory. All the rest of<br>
those "wasted" addresses can be used for something else.<br>
<br>
So what should the wasted addresses be used for? Immediate objects.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Dave<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">best,<div>Eliot</div></div>
</div></div>