VM Maker: VMMaker.oscog-eem.2833.mcz

 
Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2833.mcz

==================== Summary ====================

Name: VMMaker.oscog-eem.2833
Author: eem
Time: 4 October 2020, 7:39:18.675104 pm
UUID: 0bd7ec4f-f422-47e5-a5ab-fdb25246de8a
Ancestors: VMMaker.oscog-eem.2832

Spur: Start commenting the shim/slimbridge scheme to provide > 8 byte alignment.

=============== Diff against VMMaker.oscog-eem.2832 ===============

Item was changed:
  CogClass subclass: #SpurMemoryManager
(excessive size, no diff calculated)

Item was added:
+ ----- Method: SpurMemoryManager>>extraAlignedBitShift (in category 'header format') -----
+ extraAlignedBitShift
+ <cmacro>
+ "bit 2 of 2-bit field above classIndex (little endian)"
+ ^24!

Item was changed:
  ----- Method: SpurMemoryManager>>headerForSlots:format:classIndex: (in category 'header format') -----
  headerForSlots: numSlots format: formatField classIndex: classIndex
  <api>
  "The header format in LSB is
  MSB: | 8: numSlots | (on a byte boundary)
  | 2 bits | (msb,lsb = {isMarked,?})
  | 22: identityHash | (on a word boundary)
  | 3 bits | (msb <-> lsb = {isGrey,isPinned,isRemembered}
  | 5: format | (on a byte boundary)
+ | 2 bits | (msb,lsb = {isImmutable,isExtraAligned})
- | 2 bits | (msb,lsb = {isImmutable,?})
  | 22: classIndex | (on a word boundary) : LSB
  The remaining bits (7) are used for
  isImmutable (bit 23)
  isRemembered (bit 29)
  isPinned (bit 30)
  isGrey (bit 31)
  isMarked (bit 55)
  leaving 2 unused bits, each next to a 22-bit field, allowing those fields to be
  expanded to 23 bits..  The three bit field { isGrey, isPinned, isRemembered }
  is for bits that are never set in young objects.  This allows the remembered
  table to be pruned when full by using these bits as a reference count of
  newSpace objects from the remembered table. Objects with a high count
  should be tenured to prune the remembered table."
  <returnTypeC: #usqLong>
  <inline: true>
  ^ ((self cCoerceSimple: numSlots to: #usqLong) << self numSlotsFullShift)
  + (formatField << self formatShift)
  + classIndex!

Item was added:
+ ----- Method: SpurMemoryManager>>isExtraAligned: (in category 'header access') -----
+ isExtraAligned: objOop
+ "An object that has greater than 8 byte alignment has the isExtraAligned but set and is (must be) preceded
+ by a slimbridge.  The actual alignment the object has is held in the slimbridge.  Hence an object already
+ aligned on an N word boundary, for N > 1, must be preceded by an N word slimbridge.  We support
+ alignment slimbridges by noting that an overflow size word must have a slot count of at least 255. Any value
+ less than 128 indicates a slim bridge, which gives us 7 bits, organized as a 3-bit alignment field (in bits 4 to 6),
+ and a 4-bit bridge size field (in bIts 0 to 3).  The bridge size field gives the size minus one in words of the
+ slimbridge.  A size of zero specifies an 8-byte, one word slimbridge, a size of 15 implies an 128 byte, 16 word
+ slimbridge. The two bit alignment field gives the power of two minus three in bytes.  An alignment field of 0
+ imples 8 byte alignment (and hence is only used with single word slimbridges). An alignment field of 1 imples
+ 16 byte alignment (and hence may be used with one or two word slimbridges). An alignment field of 2 imples
+ 32 byte alignment (and hence may be used with one to four word slimbridges). An alignment field of 3 imples
+ 64 byte alignment (and hence may be used with one to eight word slimbridges). An alignment field of 4 imples
+ 128 byte alignment (and hence may be used with one to sixteed word slimbridges). Alignments of 256, 512,
+ and 1024 bytes are representable, but require a larger size field than can fit in four bits, and so are not used.
+
+ So to align an object on a 16, 32, or 128 byte boundary, at allocation time a slimbridge of the size required
+ to pad to the required alignment is written into memory, and immediatrly following it the object is allocated,
+ with its isExtraAligned bit set. The required/actual alignment is written into the slimbridge's alignment field,
+ and the entire field (saturated size count and slot count < 128) replicated in all words of the slimbridge.
+ When the object is moved, either during scavenging or compaction, when it is written into its new location,
+ a new slimbridge is synthesized to align it in the new location on the same boundary.  But the size of slimbridge
+ may be entirely different in the new location.  Only the alignment field and the object's actual alignment is
+ guaranteed not to change.  Note also that objects with an overflow size field require one word less padding in
+ the slimbridge, because it is the word following the normal header word that is aligned, not the header word
+ and not the overflow header word."
+ ^((self longAt: objOop) >> self extraAlignedBitShift bitAnd: 1) ~= 0!