[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