[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