[Vm-dev] Re: [Pharo-project] [Ann] Ephemerons for Cog

[Gerardo Richarte]

Isn't it would be simpler to treat machine code to be 'alive' as long
> as its corresponding compiled method are alive as well?
> And objects , reachable directly from compiled method are the same as
> reachable from machine code. No?

Tracing objects have two ends, keeping reachable alive,
and fixing references if the referred object moves.

Even if we could assume that tracing and marking could be done
without paying attention to the native code, fixing the references will
still need some knowledge of native code.

Two observations about this:

. While a CompiledMethod is being executed in its native form,
and if this same CompiledMethod changes itself, for example,
the two versions of the CompiledMethod should be kept alive,
and the only references to the literals in the old CompiledMethod
could be the native code itself. Unless you somehow keep a reference
to the old CompiledMethod (for example, in the stack).

. An alternative option to fix the references from native methods,
is to have arrays of pairs, Object-Offset. Where the object is what's
pointed to by the native array, and the offset is where in the code
cache the reference is. Regular GC will fix this auxiliary arrays,
and a final step in GC should fix the native references.

I'm not sure about Cog, but I'm sure that at least one other VM
implements this later technique.

It has three different references from native code to Objects,
and one is special: literals referred from CompiledMethods are
inlined references from native code. The CompiledMethod itself
is referenced from native code, as it's pushed into the stack on
the prologue. And finally, the "class pointer" of the receiver is
checked in the prologue to see if the receiver is of the right
"class".

This last references, lets call them classCheckReferences, are modified
when there's polymorphism and the same native code is activated for
a different class. For this case we would need to also change the class
in the auxiliary array, but to do that we'd need to know where to change
it, etc. It could have been an indirect reference through the auxiliary
array,
however, the auxiliary array may also move, so we enter a circle.

The solution is to just have offsets in the auxiliary array for
classCheckReferences.
The GC walks this array in a special way: dereferencing the "offsets", and
treating that word in the code cache as a regular object slot. This is
one way
of knowing how to trace into the native code for object references.

You could also have some special format with metainformation on every native
code, to tell where the references are. Or you could make all references
indirect
through the PC (on platforms where it's supported), and have all references
togehter in memory, etc.

oh well... I hope you skipped part of this :)
or otherwise, I hope it was helpful

    gera