[Vm-dev] [Pharo-project] Plan/discussion/communication around
new object format
Henrik Sperre Johansen
henrik.s.johansen at veloxit.no
Mon Jun 18 15:00:31 UTC 2012
On 18.06.2012 14:48, Levente Uzonyi wrote:
> On Mon, 18 Jun 2012, Henrik Sperre Johansen wrote:
>> On 17.06.2012 07:09, Levente Uzonyi wrote:
>>> On Sat, 16 Jun 2012, Igor Stasenko wrote:
>>>> Well, we can have it either mandatory or optional (if bit set). It is
>>>> implementation detail
>>>> and we actually should test which one is more efficient in terms of
>>>> speed/space tradeoff :)
>>>> But if it mandatory, then it combines quite well with lazy become.
>>>> The lazy become requires at least one extra word per object to store
>>>> forwarding pointer there,
>>>> because you cannot replace an object's header with forwarding pointer,
>>>> because header
>>>> holds an information how much memory is reserved for given object, and
>>>> if you wipe that information,
>>>> you will have big problems walking the memory heap and condensing
>>>> unused space.
>>> If objects are aligned to 4 (or 8) bytes then there are 2 (or 3)
>>> free bits per pointer. If you use two of these bits to store 3
>>> states: valid object, forwarded object with no slots, forwared
>>> object with slots (object size is stored in next slot) and the
>>> object header also uses these 2 bits the same way, then you don't
>>> need the extra word and you can find out the size of the forwarded
>> Those bits are already used for immediate objects, no?
> It's a new object format, everything is possible.
Sure, everything is possible.
But is it realistic/useful?
> Since my suggestion only uses 3 states, there's at least one more
> which can be used for immediates even if only 2 bits are available.
Yes, and you're down to at most 61/60 bit immediate ints/doubles, 59 if
the originally proposed lookup-table format were to be used.
Considering only instances of classes with *no* slots (if you don't have
state, why are you bothering making instances to begin with?) would end
up using less space from this scheme, I don't see how it warrants using
twice the header bits, and a lower range for immediates over just
ensuring the minimum object size including the header is 16 bytes.
More information about the Vm-dev