[Vm-dev] pinning GC

[Igor Stasenko]

On 12 January 2011 10:37, Josh Gargus <josh at schwa.ca> wrote:
>
>
> On Jan 11, 2011, at 11:48 PM, Igor Stasenko wrote:
>
>>
>> Eliot, one thing about 'forwarded' objects, which you calling the
>> forwarding corpse is that it can be used not only for pinning,
>> but also with #becomeForward primitive, making it work a lot faster,
>> since its not require to scan whole heap to update references,
>> and update can be done during GC.
>> The only problem, as you pointed out, is the objects which don't have
>> enough space for forwarding pointer. But for this case, i think the
>> primitive can fall back and use old slow scheme.
>
> I was thinking the same thing.  But wouldn't there remain the problem that Eliot mentioned about objects with named variables?
>

I was thinking about this problem before and was not really happy
about potential solutions of it.
In fact, it would be really nice to introduce a generic model for
forwarded objects,
which then could be used not just for FFI & #become but could also
serve as a transparent proxies.

It would be good to finally get rid of compact classes, so every
object will have 2 words header,
which is enough for encoding a forwarding pointer in class slot (or
use some flag to indicate that oop is forwarded and encode an index in
forwarding table).

But of course, the problem here that some bytecode are accessing the
object state directly, like reading/writing ivars,
so a code like following will break the system:

myMethod

  x := 1.
  self becomeForward: y.
  x := 5.

in the above, x is an instance variable of receiver.
If become primitive turns receiver oop into forwarding corpse, now we
have a problem that
after returning back to given method, a bytecode will attempt to write
new ivar value at old location,
instead of a new one, since receiver reference are not updated and
still points to old object memory location.

One possible solution might be that at the point of context
activation, right before starting interpreting the bytecode,
an interpreter should check if receiver is a forwarded oop, and if so,
then resolve the address of forwarded oop and use it as receiver
instead.


> Cheers,
> Josh
>


-- 
Best regards,
Igor Stasenko AKA sig.