Porting troubles

Georg Gollmann gollmann at edvz.tuwien.ac.at
Mon Aug 24 11:33:39 UTC 1998

I wrote:

>As a learning experience I have tried porting Squeak to Linux/m68k (Debian
>2.0beta). While the make process ran without a problem (thanks Ian!) I
>quickly faced a segmentation fault when running Squeak (in the
>incrementalGC when the lowSpaceWatcher is installed, to be precise).
>As I read it the memory has been malloced high up and all those ints that
>represent addresses have become negative, breaking the pointer arithmetic.

Some further investigations showed that the real problem is clearly stated
in ObjectMemory>fwdTableInit:
 (checkAssertions and: [(fwdTableLast bitAnd: MarkBit) ~= 0]) ifTrue: [
  "Note: Address bits must not interfere with the mark bit in header of
   an object, which shows that the object is forwarded."
   self error: 'fwd table must be in low half of the 32-bit address space'.

The object header of a forwarded object looks like this
Bit 0-1  TypeMask
Bit 2-30 OOP of forward block minus the two low order bits which
         are always zero
Bit 31   MaskBit

To make Squeak 32 bit clean I see a couple of solutions:

1) Use type code 2 which is currently unused (outside the mark phase) to
signify "forwarded" and adjust methods that need the type code to look at
the forwarding block. This would cost some(?) performance.

2) Ensure that forwarding blocks are quadword aligned (by adding 4 to
fwdTableNext in ObjectMemory>fwdTableInit if it isn´t). There are two
substrategies here:
2a) Keep the header fields and shift the forwarding OOP to convert between
stored and real OOP. This will cost some(?) performance.
2b) Move the MarkBit to bit 2 (adjacent to the type mask). This requires an
image format change.

My preference would be 2b. What do the VM gurus say ?


Dipl.Ing. Georg Gollmann                   TU-Wien, EDV-Zentrum

phon:(+43-1) 58801 - 5848
fax: (+43-1) 587 42 11
mail:gollmann at edvz.tuwien.ac.at

More information about the Squeak-dev mailing list