[Vm-dev] VM Maker: VMMaker.oscog-eem.2833.mcz

commits at source.squeak.org commits at source.squeak.org
Mon Oct 5 02:39:26 UTC 2020


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!



More information about the Vm-dev mailing list