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

[Igor Stasenko]

btw, i am still wondering if it necessary to know exact size in bytes
of compiled method.
I think we could align its size to 8 bytes without much loss. then it
will take single place (value) in format instead of 8.

Of course, for bytearrays we cannot do same trick, since then we will
have not container left which can
hold data with size aligned to single byte.


On 23 September 2011 12:58, Igor Stasenko <siguctua at gmail.com> wrote:
> 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.
>



-- 
Best regards,
Igor Stasenko.