[Vm-dev] VM Maker: VMMaker.oscog.seperateMarking-eem.3277.mcz
commits at source.squeak.org
commits at source.squeak.org
Fri Dec 2 23:11:34 UTC 2022
Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog.seperateMarking-eem.3277.mcz
==================== Summary ====================
Name: VMMaker.oscog.seperateMarking-eem.3277
Author: eem
Time: 2 December 2022, 3:11:14.645403 pm
UUID: 1cfb2671-c680-4912-8404-dbe6e2532726
Ancestors: VMMaker.oscog.seperateMarking-WoC.3276
Add/update/spell check SpurMemoryManager and subclass class comments.
=============== Diff against VMMaker.oscog.seperateMarking-WoC.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)
More information about the Vm-dev
mailing list