Hi All,
in lieu of some full posts on the Cog JIT here’s a screencast that gives a brief overview of some image level info for the Cog VM before diving into the simulator and looking at the evolution of a send site in the VM through various forms of inline cache.
John McKeon | 25-Jul-10 at 9:02 am | Permalink
Hi Elliot,
This screen cast won’t run for me. I click the play button, it looks like it is starting to play (the button turns into the pause button, etc), then it stops, nada.
Any ideas?
Your post on context to frame mapping is both illuminating and mind bending. As a plain old squeak user (and quite the newbie at that) I find this “under the hood” stuff fascinating and daunting at the same time…
Thanks for all of your hard work
John
Carl Gundel | 27-Jul-10 at 9:32 am | Permalink
Thanks for putting this together Eliot. I’m always fascinated by what you’re working on. Keep it coming!
Smalltalk Solutions or bust!
Igor Stasenko | 10-Oct-10 at 5:58 pm | Permalink
Hi, Elliot
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.
Eliot Miranda | 17-Oct-10 at 12:35 pm | Permalink
Hi Igor,
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")