[Vm-dev] Re: [Pharo-project] Integrating Changes in 1.4 that require a new VM

[Igor Stasenko]

On 23 September 2011 09:44, stephane ducasse <stephane.ducasse at gmail.com> wrote:
>
> Stupid question:
>
> what does it mean?
>> we need 8 CompiledMethod values
>
to encode odd size values.
The header encoding size in machine words, which on 64 bit system are
always 8-byte aligned.
But compiled method size could be any size in bytes and to encode it
we need 3 bits somewhere (or 8 different values),
to encode size in bytes i.e.:

sizeinbytes = sizeInWords*8 + (oddSize)

where oddsize is our 0..7 value

> Stef
>
>>
>>
>> Here's the format field (Behavior>instSpec at the image level) as currently populated:
>>
>>   0 = 0 sized objects (UndefinedObject True False et al)
>>   1 = non-indexable objects with inst vars (Point et al)
>>   2 = indexable objects with no inst vars (Array et al)
>>   3 = indexable objects with inst vars (MethodContext AdditionalMethodState et al)
>>   4 = weak indexable objects with inst vars (WeakArray et al)
>>   6 = 32-bit indexable objects (Float, Bitmap ert al)
>>   8 = 8-bit indexable objects (ByteString, ByteArray et al)
>> 12 = CompiledMethod
>>
>> N.B. in the VM the least two bits of the format/instSpec for byte objects (formats 8 and 12) is used to encode the number of odd bytes in the object, so that a 1 character ByteString has a format of 11, = 8 + 3, size = 1 word - 3 bytes.
>>
>>
>> For the future (i.e. the new GC/object representation, /not/ for the first implementation of ephemerons which we can do now, for Pharo 1.4 or 1.5) we need to extend format/instSpec to support 64 bits.  I think format needs to be made a 5 bit field with room for 4 bits of odd bytes for 64-bit images.  [For VMers, the Size4Bit is a horrible hack).  So then
>>
>> 0 = 0 sized objects (UndefinedObject True False et al)
>> 1 = non-indexable objects with inst vars (Point et al)
>> 2 = indexable objects with no inst vars (Array et al)
>> 3 = indexable objects with inst vars (MethodContext AdditionalMethodState et al)
>> 4 = weak indexable objects with inst vars (WeakArray et al)
>> 5 = weak non-indexable objects with inst vars (ephemerons) (Ephemeron)
>>
>> and we need 8 CompiledMethod values, 8 byte values, 4 16-bit values, 2 32-bit values and a 64-bit value, = 23 values, 23 + 5 = 30, so there is room, e.g.
>>
>> 9 (?) 64-bit indexable
>> 10 - 11 32-bit indexable
>> 12 - 15 16-bit indexable
>> 16 - 23 byte indexable
>> 24 - 31 compiled method
>>
>> In 32-bit images only the least significant 2 bits would be used for formats 16 & 24, and the least significant bit for format 12.
>>
>>
>



-- 
Best regards,
Igor Stasenko.