Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2971.mcz
==================== Summary ====================
Name: VMMaker.oscog-eem.2971 Author: eem Time: 20 June 2021, 10:20:32.415024 pm UUID: b9251568-d992-439d-a42e-846c5acbf5fd Ancestors: VMMaker.oscog-eem.2970
Image segment loading creates objects that are ambiguous with newspace slimbridges. Beef up slimbridge parsing (objectAfterMaybeSlimBridge:limit:) so that objects in oldSpace are not confused with them. [the shim idea will need to be thought through carefully w.r.t. shortening objects]
=============== Diff against VMMaker.oscog-eem.2970 ===============
Item was changed: ----- Method: Spur32BitMemoryManager>>objectAfterMaybeSlimBridge:limit: (in category 'object enumeration-private') ----- objectAfterMaybeSlimBridge: objOop limit: limit "Object parsing. 1. all objects have at least a word following the header, for a forwarding pointer. 2. objects with an overflow size have a preceding word with a saturated numSlots. If the word following an object doesn't have a saturated numSlots field it must be a single-header object. If the word following does have a saturated numSlots it must be the overflow size word. This variation on objectAfter:limit: allows for a single (64-bit) word bridge which may be needed to bridge from an almost full pastSpace to eden. It is only used in the flat enumerators that use startAddressForBridgedHeapEnumeration and enumerate over pastSpace, eden and oldSpace in that order. Note that the order for allObjects, and allInstances enumerates over oldSpace first.
This hack is cheap. It increases the size of the objectAfter code, but saves two extra copies of the inner loop, since the inner loop now enumerates over all of pastSpace, eden and oldSpace. The test for a slim bridge is only performed if applied to an overflow header, and typically only + 1 in 400 objects have overflow headers in 32-bits, 1 in 500 in 64-bits. The complication is that + image segment loading evaporates the word array by setting the overflow slots to 1, and this + is ambiguous with a slimbridge. The resolution is that slimbridges are used only in new space." - 1 in 400 objects have overflow headers in 32-bits, 1 in 500 in 64-bits." <inline: true> | followingWordAddress followingWord | followingWordAddress := self addressAfter: objOop. (self oop: followingWordAddress isGreaterThanOrEqualTo: limit) ifTrue: [^limit]. self flag: #endianness. followingWord := self longAt: followingWordAddress + 4. ^followingWord >> self numSlotsHalfShift = self numSlotsMask + ifTrue: [((self oop: objOop isGreaterThanOrEqualTo: oldSpaceStart) + and: [1 = (self longAt: followingWordAddress)]) "i.e. the raw overflow slots in the overflow word" - ifTrue: [1 = (self longAt: followingWordAddress) "i.e. the raw overflow slots in the overflow word" ifTrue: [followingWordAddress + self baseHeaderSize + self baseHeaderSize] ifFalse: [followingWordAddress + self baseHeaderSize]] ifFalse: [followingWordAddress]!
Item was changed: ----- Method: Spur32BitMemoryManager>>rawOverflowSlotsOf:put: (in category 'object access') ----- rawOverflowSlotsOf: objOop put: numSlots <returnTypeC: #usqInt> <inline: true> self flag: #endianness. + self deny: (numSlots = 1 and: [self oop: objOop isLessThan: newSpaceLimit]). "otherwise ambiguous with a slimbridge" ^self longAt: objOop - self baseHeaderSize put: numSlots!
Item was changed: ----- Method: Spur64BitMemoryManager>>objectAfterMaybeSlimBridge:limit: (in category 'object enumeration-private') ----- objectAfterMaybeSlimBridge: objOop limit: limit "Object parsing. 1. all objects have at least a word following the header, for a forwarding pointer. 2. objects with an overflow size have a preceding word with a saturated numSlots. If the word following an object doesn't have a saturated numSlots field it must be a single-header object. If the word following does have a saturated numSlots it must be the overflow size word. This variation on objectAfter:limit: allows for a single (64-bit) word bridge which may be needed to bridge from an almost full pastSpace to eden. It is only used in the flat enumerators that use startAddressForBridgedHeapEnumeration and enumerate over pastSpace, eden and oldSpace in that order. Note that the order for allObjects, and allInstances enumerates over oldSpace first.
This hack is cheap. It increases the size of the objectAfter code, but saves two extra copies of the inner loop, since the inner loop now enumerates over all of pastSpace, eden and oldSpace. The test for a slim bridge is only performed if applied to an overflow header, and typically only + 1 in 400 objects have overflow headers in 32-bits, 1 in 500 in 64-bits. The complication is that + image segment loading evaporates the word array by setting the overflow slots to 1, and this + is ambiguous with a slimbridge. The resolution is that slimbridges are used only in new space." - 1 in 400 objects have overflow headers in 32-bits, 1 in 500 in 64-bits." <inline: true> | followingWordAddress followingWord | followingWordAddress := self addressAfter: objOop. (self oop: followingWordAddress isGreaterThanOrEqualTo: limit) ifTrue: [^limit]. self flag: #endianness. followingWord := self longAt: followingWordAddress. ^followingWord >> self numSlotsFullShift = self numSlotsMask ifTrue: + [((self oop: objOop isGreaterThanOrEqualTo: oldSpaceStart) + and: [(followingWord bitAnd: 16rFFFFFFFFFFFFFF) = 1]) - [(followingWord bitAnd: 16rFFFFFFFFFFFFFF) = 1 ifTrue: [followingWordAddress + self baseHeaderSize + self baseHeaderSize] ifFalse: [followingWordAddress + self baseHeaderSize]] ifFalse: [followingWordAddress]!
Item was changed: ----- Method: Spur64BitMemoryManager>>rawOverflowSlotsOf:put: (in category 'object access') ----- rawOverflowSlotsOf: objOop put: numSlots <returnTypeC: #usqLong> <inline: true> self flag: #endianness. + self deny: (numSlots = 1 and: [self oop: objOop isLessThan: newSpaceLimit]). "otherwise ambiguous with a slimbridge" self longAt: objOop - self baseHeaderSize put: self numSlotsMask << 56 + numSlots. ^numSlots!
vm-dev@lists.squeakfoundation.org