[Vm-dev] [Pharo-project] Plan/discussion/communication around new object format

[Henrik Sperre Johansen]

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 
>>> objects.
>> 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.

Cheers,
Henry