Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.3277.mcz
==================== Summary ====================
Name: VMMaker.oscog-eem.3277 Author: eem Time: 2 December 2022, 2:57:28.506161 pm UUID: 6e367e56-0fc2-488c-b78c-37d2029e0ffc Ancestors: VMMaker.oscog-eem.3276
Add/update/spell check SpurMemoryManager and subclass class comments.
=============== Diff against VMMaker.oscog-eem.3276 ===============
Item was changed: Spur32BitMemoryManager subclass: #Spur32BitCoMemoryManager instanceVariableNames: 'cogit' classVariableNames: '' poolDictionaries: 'CogMethodConstants' category: 'VMMaker-SpurMemoryManager'!
+ !Spur32BitCoMemoryManager commentStamp: 'eem 12/2/2022 14:04' prior: 0! - !Spur32BitCoMemoryManager commentStamp: 'eem 11/25/2013 14:47' prior: 0! Spur32BitCoMemoryManager is a refinement of Spur32BitMemoryManager that supports the CoInterpreter/Cogit just-in-time compiler. The significant difference from Spur32BitMemoryManager is the memory layout. Spur32BitCoMemoryManager adds the cogCodeZone beneath newSpace:
low address: cogCodeZone: generated run-time cog methods free space young referrers newSpace: past/future survivor space future/past survivor space eden first oldSpace segment ... subsequent oldSpace segment high address:
+ It would be convenient if the code zone were placed between newSpace and oldSpace; then Cog methods could be considered neither old nor young, filtering them out of copyAndForward: and the store check with single bounds checks. But the CoInterpreter already assumes Cog methods are less than all objects (e.g. in its isMachineCodeFrame:). If the dynamic frequency of isMachineCodeFrame: is higher (likely because this is used in e.g. scanning for unwind protects in non-local return) then it should keep the single bounds check. So the code zone remains beneath newSpace and Spur32BitCoMemoryManager overrides isReallyYoungObject: to filter-out Cog methods for copyAndForward:. - It would be convenient if the code zone were placed between newSpace and oldSpace; then Cog methods could be onsidered neither old nor young, filtering them out of copyAndForward: and the store check with single bounds checks. But the CoInterpreter already assumes Cog methods are less than all objects (e.g. in its isMachineCodeFrame:). If the dynamic frequency of isMachineCodeFrame: is higher (likely because this is used in e.g. scanning for unwind protects in non-local return) then it should keep the single bounds check. So the coder zone remains beneath newSpace and Spur32BitCoMemoryManager ocerrides isReallyYoungObject: to filter-out Cog methods for copyAndForward:.
Instance Variables cogit: <SimpleStackBasedCogit or subclass>
cogit - the just-in-time compiler!
Item was changed: SpurMemoryManager subclass: #Spur32BitMemoryManager instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'VMMaker-SpurMemoryManager'! + + !Spur32BitMemoryManager commentStamp: 'eem 12/2/2022 14:03' prior: 0! + A Spur32BitMemoryManager is the concrete class for the 32-bit variant of Spur as used with the StackInterpreter. When using the Spur32BitMemoryManager, objects on the heap have the normal 64-bit or 128-bit header, but objects have 32-bit fields. Since objects are aligned on 64-bit boundaries, the smallest object is 128-bits in length, having a 64-bit header and two empty 32-bit fields, the first of which is used for the forwarding pointer. + + Instance Variables!
Item was changed: Spur64BitMemoryManager subclass: #Spur64BitCoMemoryManager instanceVariableNames: 'cogit' classVariableNames: '' poolDictionaries: 'CogMethodConstants' category: 'VMMaker-SpurMemoryManager'!
+ !Spur64BitCoMemoryManager commentStamp: 'eem 12/2/2022 14:04' prior: 0! - !Spur64BitCoMemoryManager commentStamp: 'eem 11/25/2013 14:47' prior: 0! Spur64BitCoMemoryManager is a refinement of Spur64BitMemoryManager that supports the CoInterpreter/Cogit just-in-time compiler. The significant difference from Spur64BitMemoryManager is the memory layout. Spur64BitCoMemoryManager adds the cogCodeZone beneath newSpace:
low address: cogCodeZone: generated run-time cog methods free space young referrers newSpace: past/future survivor space future/past survivor space eden first oldSpace segment ... subsequent oldSpace segment high address:
+ It would be convenient if the code zone were placed between newSpace and oldSpace; then Cog methods could be considered neither old nor young, filtering them out of copyAndForward: and the store check with single bounds checks. But the CoInterpreter already assumes Cog methods are less than all objects (e.g. in its isMachineCodeFrame:). If the dynamic frequency of isMachineCodeFrame: is higher (likely because this is used in e.g. scanning for unwind protects in non-local return) then it should keep the single bounds check. So the code zone remains beneath newSpace and Spur32BitCoMemoryManager overrides isReallyYoungObject: to filter-out Cog methods for copyAndForward:. - It would be convenient if the code zone were placed between newSpace and oldSpace; then Cog methods could be onsidered neither old nor young, filtering them out of copyAndForward: and the store check with single bounds checks. But the CoInterpreter already assumes Cog methods are less than all objects (e.g. in its isMachineCodeFrame:). If the dynamic frequency of isMachineCodeFrame: is higher (likely because this is used in e.g. scanning for unwind protects in non-local return) then it should keep the single bounds check. So the coder zone remains beneath newSpace and Spur64BitCoMemoryManager ocerrides isReallyYoungObject: to filter-out Cog methods for copyAndForward:.
Instance Variables cogit: <SimpleStackBasedCogit or subclass>
cogit - the just-in-time compiler!
Item was changed: SpurMemoryManager subclass: #Spur64BitMemoryManager instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'VMMaker-SpurMemoryManager'! + + !Spur64BitMemoryManager commentStamp: 'eem 12/2/2022 14:03' prior: 0! + A Spur64BitMemoryManager is the concrete class for the 64-bit variant of Spur as used with the StackInterpreter. When using the Spur64BitMemoryManager, objects on the heap have the normal 64-bit or 128-bit header, and objects have 64-bit fields. Since objects are aligned on 64-bit boundaries, the smallest object is 128-bits in length, having a 64-bit header and one empty 64-bit field for the forwarding pointer. + + Instance Variables + + Instance Variables + !
Item was changed: CogClass subclass: #SpurMemoryManager (excessive size, no diff calculated)
vm-dev@lists.squeakfoundation.org