[Vm-dev] Questions about Cog internals

[Mariano Martinez Peck]

Hi Eliot. I am really trying (with all my lack of knowledge) to understand a
little about how Cog works internally. I am also reading your posts, and I
have a couple of (probably newbie) questions. If any of them are answered in
the blog, please point me to them (I couldn't ream all of them yet):

1) Suppose you have a CompiledMethod XXX that you JIT, and you get a
CogMethod YYY. While doing the GC (#lastPointersOf:,
#lastPointerWhileForwarding:, etc), you need to check whether XXX is a
CogMethodReference because if so, you need to fetch XXX header from YYY.
Perfect. To avoid the GC to look in the CogMethod "objects" you put a header
with the special format for empty objects, hence the GC doesn't follow the
non-existent "instVars" of CogMethod. Perfect. CogMethod has a pointer to
its original CM (back-pointer), called 'methodObject'. In this case, YYY has
a pointer to XXX. So....my question is, during a GC compaction or a #become,
where the address of XXX is changed, how do you update YYY so that to point
to the new address of XXX?   because if you flag YYY as an empy object, then
the GC doesn't update it.

2) As far as I understand, CogMethod doesn't "store/duplicate" the literals
of the CompiledMethod. Hence, even when you have a jitted method, when you
need a special literal, you ask it to the CM, using the backPointer
'methodObject'. Is this correct ?

3) This is the most stupid question, but I don't see WHERE the machine code
is kept. When I jit a method, I get a structure CogMethod, perfect. What
where is the generated machine code? where is it kept? how can I know from a
CogMethod which is the associated machine code?

4) I guess that my thought of 2) is not correct, because otherwise, I don't
understand why you need CoInterpreter >>markAndTraceOrFreeMachineCode:. The
comments says "Deal with a fulGC's effects on machine code.  Either mark and
trace oops in machine code or free machine-code methds that refer to freed
oops.  The stack pages have already been traced so any method  of live stack
activations have already been marked and traced."

which oops do you mean by "oops in machine code" ? literals? the back-poiner
to the CM?

and by " free machine-code methods that refer to freed  oops"  what do you
mean?  literals or oops as the back pointer?  I can think you refer to the
backpointer since the original CM could have been garbage collected and
since you flag the CogMethod as empty...

5) This is not a question, but rather that I would like to know whether I
understood correctly or not. You Jit a method when it is secondly used, that
is, when you find it in the cache. To know how to generate the machine code
or a particular bytecode, you check in the table that you generate wth
#initializeBytecodeTableForClosureV3 where you basically map bytecodes to
methods that generates the machine code of such bytecode. If it is a
primitive you use instead #compilePrimitive which cecks in a similar table,
but for primitives, which is set in #initializePrimitiveTableForSqueakV3.

Now, I have compiled method XXX (selector xxx) which sends #foo. XXX was
jitted to CogMethod YYY (selector yyy).   When xxx is executed, YYY is
executed. When YYY was jitted, you defined in
#initializeBytecodeTableForClosureV3  that it just be a specific method,
which at the end, for normal messages it is:  #genSend:numArgs:. That method
to generate the machine code includes the "trampoline" (which is searched in
'sendTrampolines', and in #generateSendTrampolines we can see how you map
from one to the other one) and sends the associated message, in this case,
#ceSend:super:to:numArgs:. So...the #foo will be finally "handle" in
ceSend:super:to:numArgs:.  This is ONLY true if the send was "unlinked".  If
#foo in fact was jitted also, then you try to link it (to avoid searching in
cache next times???). Suppose you could link both of them,so next time YYY
is executed, it will call DIRECTLY the CogMethod of #foo. In this case, the
method to be executed in the VM is
#executeCogMethodFromLinkedSend:withReceiver:   instead of
#ceSend:super:to:numArgs:

So..I am delirious or that is more or less correct ?

Thanks a lot in advance,

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110503/dc3b3b5d/attachment-0001.htm