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

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

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

Name: VMMaker.oscog-eem.2958
Author: eem
Time: 10 May 2021, 7:19:28.320827 pm
UUID: 972e62ae-ea8b-4399-8619-b0e9e01d83de
Ancestors: VMMaker.oscog-eem.2957

spelling in a comment only. this is not the commit you're looking for.

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

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
- to bridge from an almost full pastSpace to eden.  It is ony 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."
  <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: [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: 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
- to bridge from an almost full pastSpace to eden.  It is ony 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."
  <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:
  [(followingWord bitAnd: 16rFFFFFFFFFFFFFF) = 1
  ifTrue: [followingWordAddress + self baseHeaderSize + self baseHeaderSize]
  ifFalse: [followingWordAddress + self baseHeaderSize]]
  ifFalse: [followingWordAddress]!

Item was changed:
  ----- Method: SpurMemoryManager>>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
- to bridge from an almost full pastSpace to eden.  It is ony 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."
  ^self subclassResponsibility!