[Mono-dev] RFC: GC precise scanning of stacks

[Rodrigo Kumpera]

Hey Dick,

Your patch won't work because it doesn't deal neither with on stack
temporaries or spilled variables
and can make the runtime somewhat slower since it marks as volatile all
locals holding managed objects.

It would not work for the top frame due to how threads are stopped by boehm
or sgen. Both collectors
park threads at random points[1] without any sort of safe-point mechanism.

There are a few ways to implement precise stack scanning for unmanaged code,
none are pretty thou:

-Make the whole runtime use gchandles to manipulate managed objects. Safe
parking is possible to be done
in a quite non-intrusive way. Coding using such thing is a major PITA as all
access have to be done using accessor
functions. The main issue with this approach is the __huge__ effort to fix
all code playing with managed objects.

-Only scan unmanaged frames from the runtime or DSOs that have registered
icalls. This is a pretty decent
compromise and should lead to a lot less false positives.

For managed code, we need to extend the JIT to either produce stack maps
that tell at each safepoint[2] which
stack slots are used for managed pointer and which are unknown (callee saved
regs, for example); or we can just
make sure stack slot for managed pointers are not reused for scalars, have a
single description of the stack and live
with some false positives due to uninitialized variables.

We could use a shadow stack for the JITd code, which is quite simples to
implement, but it has the issue of causing
slower code to be generated.


[1] SGen requires parking outside of allocators but otherwise it can be at
arbitrary points.
[2] Safepoints can pretty much be just at method call points since the top
frame will most likely be conservatively scanned.



On Mon, Sep 28, 2009 at 10:28 AM, Dick Porter <dporter at codicesoftware.com>wrote:

> Hi all
>
> We think some of our 'leak' issues can be attributed to libgc's
> false-positive identification of pointers.
>
> Attached is a proof-of-concept patch to libgc (and a simple
> demonstration program) that I hope will be the start of GC precise stack
> scanning.  The code should apply easily to sgen as well.
>
> It basically adds an extra variable to the stack which contains specific
> markers and references to all the pointers that will contain GC-alloced
> memory.  There is an optional failsafe mode that will fall back to the
> current 'all stack is scanned' code if the markers are not seen.
>
> This code will cover objects on unmanaged stacks but I don't know what
> will be needed for managed code.  I presume the JIT can add the same
> sort of marker to the stack?
>
> So, comments?  Is this technique going to be workable?
>
> - Dick
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20091017/66418465/attachment.html