you have to balance the cost of GC against the cost of the extra indirection. Since GCs are relatively rare I think it’s better to concentrate on runtime performance. Remember, dedicating a register to point to objects means an extra register to save and restore around every send, not just method activation.

But GC time is important and Cog takes care to minimise the amount of work done scanning machine code. It does this by maintaining a list of native methods that contain references to objects in newSpace. See CogMethodZone>youngReferrers. So on incremental GC only those methods that contain young object references are scanned and, you guessed it, in the normal case the young referrers list is empty. Only when you compile new code or do a become does the young referrer list get populated.

As far as the metadata goes that’s of the order of one byte per reference and that’s only a third of all metadata. Eliminating them would only save 1.4% of the used space, only a little more than the extra 4 bytes needed in a method to refer to its indirect literals, ignoring the size taken by the extra save-restore code for the indirect references.

In summary keeping object references in machine code may appear costly but it is both more efficient and not a problem for GC in practice since few if any methods refer to new objects and global garbage collections are extremely rare.

FYI here’s the code I used to gather the above stats (I had to write Cogit>>mapFor:do: and will add it to the VMMaker package soon). I ran an image under Cog and measured the state after start-up:

| annotations num nmethods types |
annotations := Bag new.
nmethods := num := 0.
self methodsDo:
	[:m|
	m cmType = CMMethod ifTrue:
		[nmethods := nmethods + 1.
		cogit mapFor: m do: [:ann :pc| num := num + 1.  annotations add: ann. false]]].
		"table copied from Cogit class>>initializeAnnotationConstants"
types := #(	IsSendCall
		IsRelativeCall
		HasBytecodePC
		IsMethodReference
		IsObjectReference
		nil
		nil) reverse.
{ nmethods. num. (annotations sortedCounts collect: [:assoc| { assoc key * 100 / num roundTo: 0.1. assoc key. types at: assoc value }]) }

#("nmethods" 1366
   "nannotations:" 19688
#(#(33.1 6510 #IsObjectReference)
    #(32.2 6336 #IsSendCall)
    #(15.3 3021 #HasBytecodePC)
    #(12.5 2458 #IsRelativeCall)
    #(6.9 1363 #IsMethodReference))

mzFreeStart - baseAddress  470320 "used space in method zone"
6510/4703.20 1.384163973464875 "percentage of used space in IsObjectReference annotations"
1366 * 4 5464 "size taken by an extra pointer per method to indirect literals"

)

i wonder if you can measure, how many cycles you losing by validating a JIT code each time you doing GC. Because for each instruction, like:

mov oop -> register

where oop is an immediate value,
you have to change it, if oop has moved in memory.
In addition to that, you have to keep a meta-information about location of this immediate in code, in order to change it.

What if you put all oops to special ‘literal frame’ of native code, and reserve a register (lets say ESI) which will point to beginning of them, then
mov oop -> register
could be changed to:
mov [ESI + offset] -> register

Moreover, this special literal frame could be a usual object , like Array instance, so GC will update pointers inside it in same way as it does for any other object(s), which having references.

Smalltalk Solutions or bust!