class formats

[Michael Haupt-3]

Hi,

apologies for the cross-post to two lists, but I wasn't too sure where
to ask this.

I've just been browsing the VM sources for details on the encoding of
class formats used in object instantiation.

Apparently, it seems as if the class format word that can be retrieved
by sending #format to a class has the same layout as the standard
header word of all objects. The only difference seems to be that the
format word is shifted left by 1.

Can anyone confirm this? Or am I wrong?

Thanks,

Michael

[Andreas Raab]

 > Can anyone confirm this? Or am I wrong?

That is exactly correct. It's a little implementation trick so that the
format doesn't have to be "normalized" for allocation. It originates
from the days when even a shift was too slow in allocation; personally I
find it a little awkward.

Cheers,
   - Andreas

Michael Haupt wrote:

> Hi,
>
> apologies for the cross-post to two lists, but I wasn't too sure where
> to ask this.
>
> I've just been browsing the VM sources for details on the encoding of
> class formats used in object instantiation.
>
> Apparently, it seems as if the class format word that can be retrieved
> by sending #format to a class has the same layout as the standard
> header word of all objects. The only difference seems to be that the
> format word is shifted left by 1.
>
> Can anyone confirm this? Or am I wrong?
>
> Thanks,
>
> Michael
>
>

[Michael Haupt-3]

Hi Andreas,

On 5/16/06, Andreas Raab <andreas.raab@...> wrote:
>  > Can anyone confirm this? Or am I wrong?
>
> That is exactly correct. It's a little implementation trick so that the
> format doesn't have to be "normalized" for allocation. It originates
> from the days when even a shift was too slow in allocation; personally I
> find it a little awkward.

thanks for your answer.

Would a reimplementation in a different way significantly speed things
up, or is that just aesthetically unsatisfying? (I suspect shifts are
faster now.)

Best,

Michael

[Andreas Raab]

Michael Haupt wrote:
>> That is exactly correct. It's a little implementation trick so that the
>> format doesn't have to be "normalized" for allocation. It originates
>> from the days when even a shift was too slow in allocation; personally I
>> find it a little awkward.
>
> Would a reimplementation in a different way significantly speed things
> up, or is that just aesthetically unsatisfying? (I suspect shifts are
> faster now.)

You won't know until you measure it ;-) But I wouldn't think there is
any difference whatsoever; it's really just unpleasing to get one number
in the image and another one in the VM (because if you do VM stuff then
then you need to look at these at times).

Cheers,
   - Andreas