[Mono-dev] field pointer and garbage collection

[Alex Rønne Petersen]

As with any pointer updating during GC, this can only be done with
precise type and liveness information. If any pointer to an object --
whether base or interior -- exists in CPU registers or on the stack,
the object is considered pinned and will not be moved. The exception
to this is when you run SGen with precise stack scanning (which is
somewhat experimental) - in this mode, SGen knows which pointers are
where on the stack and will update accordingly.

Note that CIL only allows interior pointers on the stack - you can't
take an interior pointer and store it on the heap or anything like
that.

On Wed, Jun 11, 2014 at 12:08 PM, serus <fabian.nagel at gmail.com> wrote:
> Dear Devs,
>
> I would appreciate if someone could make sense out of the following:
>
> When a field of an object is accessed in C#, the IL code is LDFLD.
> Intuitively, I would assume that the JIT compiler would transform LDFLD into
> the assembler version of the following C code:
>
> int A = *(int*)(ptr + 24);   // ptr is pointer to object, accessed field is
> int and 24 is offset of field in object
>
> Now assuming this was true, at some point (ptr + 24) would reside in a CPU
> register, if execution is intercepted by garbage collection and the object
> moved somewhere, this pointer would have to be updated as well, which sounds
> impossible as the forward pointer is installed at the beginning of the
> object and the pointer points to somewhere inside the object.
>
> What part of my assumption is wrong? How is this solved?
>
>
>
> --
> View this message in context: http://mono.1490590.n4.nabble.com/field-pointer-and-garbage-collection-tp4663040.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list