llvm dev - Sep 2010 - [LLVMdev] Patch to allow llvm.gcroot to work with non-pointer allocas.

Thanks for the heads up Chris.

Talin, how is your GC dealing with non-pointers (be it allocas or not)? What
is the use-case (either in C or LLVM)?

Nicolas

On Fri, Sep 24, 2010 at 7:00 PM, Chris Lattner <clattner at apple.com>
wrote:
> On Sep 22, 2010, at 8:52 AM, Talin wrote:
> > I'm moving this thread to llvm-dev in the hopes of reaching a
wider
> audience.
> >
> > This patch relaxes the restriction on llvm.gcroot so that it can work
> with non-pointer allocas. The only changes are to Verifier.cpp - it appears
> from my testing that llvm.gcroot always worked fine with non-pointer
> allocas, except that the verifier wouldn't allow it. I've used this
patch to
> build an efficient stack crawler (an alternative to shadow-stack that uses
> only static constant data structures.)
> >
> > Here's a deal: If you accept this patch, I'll write up an
extensive
> tutorial on how to write a stack crawler like mine. (Actually, it's
already
> written, however without this patch the tutorial doesn't make any
sense.)
>
> Hi Talin,
>
> I don't think anyone is really using the GC support, other than Nicolas
in
> VMKit.  If he's ok with the change, I am too.  Please make sure the dox
stay
> up to date though.
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100924/6581dc4c/attachment.html>

On Fri, Sep 24, 2010 at 10:44 AM, nicolas geoffray <
nicolas.geoffray at gmail.com> wrote:
> Thanks for the heads up Chris.
>
> Talin, how is your GC dealing with non-pointers (be it allocas or not)?
> What is the use-case (either in C or LLVM)?
>
Many languages support the notion of a "value type". Value types are
always
passed by value, unlike reference types which are always passed by
pointer. An example is the "struct" type in C#. Another example is a
"tuple"
type. A value type which is a local variable lives on the stack as an
alloca, not on the heap. When a function is called with a value type as
argument, the callee gets its own copy of the argument, rather than sharing
a pointer with the caller.

Value types are represented in LLVM using structs, and may contain pointer
fields which need to be traced.

The way that I handle non-pointer types is to generate an array of field
offsets (containing the offset of each pointer field within the struct) as
the metadata argument to llvm.gcroot. This meta argument is then processed
in my GCStrategy, where I add the stack root offset to the offsets in the
field offset array, which yields the stack offsets of the actual pointers in
the call frame.

It's all pretty simple really.

>
> Nicolas
>
>  On Fri, Sep 24, 2010 at 7:00 PM, Chris Lattner <clattner at
apple.com>wrote:
>
>>  On Sep 22, 2010, at 8:52 AM, Talin wrote:
>> > I'm moving this thread to llvm-dev in the hopes of reaching a
wider
>> audience.
>> >
>> > This patch relaxes the restriction on llvm.gcroot so that it can
work
>> with non-pointer allocas. The only changes are to Verifier.cpp - it
appears
>> from my testing that llvm.gcroot always worked fine with non-pointer
>> allocas, except that the verifier wouldn't allow it. I've used
this patch to
>> build an efficient stack crawler (an alternative to shadow-stack that
uses
>> only static constant data structures.)
>> >
>> > Here's a deal: If you accept this patch, I'll write up an
extensive
>> tutorial on how to write a stack crawler like mine. (Actually, it's
already
>> written, however without this patch the tutorial doesn't make any
sense.)
>>
>> Hi Talin,
>>
>> I don't think anyone is really using the GC support, other than
Nicolas in
>> VMKit.  If he's ok with the change, I am too.  Please make sure the
dox stay
>> up to date though.
>>
>> -Chris
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>

-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100924/f1726127/attachment.html>

Hi Talin,

On Sat, Sep 25, 2010 at 4:18 AM, Talin <viridia at gmail.com>
wrote:
>
>
> Many languages support the notion of a "value type". Value types
are always
> passed by value, unlike reference types which are always passed by
> pointer. An example is the "struct" type in C#. Another example
is a "tuple"
> type. A value type which is a local variable lives on the stack as an
> alloca, not on the heap. When a function is called with a value type as
> argument, the callee gets its own copy of the argument, rather than sharing
> a pointer with the caller.
>
Yes.

>
> Value types are represented in LLVM using structs, and may contain pointer
> fields which need to be traced.
>
>
Yes.

> The way that I handle non-pointer types is to generate an array of field
> offsets (containing the offset of each pointer field within the struct) as
> the metadata argument to llvm.gcroot. This meta argument is then processed
> in my GCStrategy, where I add the stack root offset to the offsets in the
> field offset array, which yields the stack offsets of the actual pointers
in
> the call frame.
>
>
Did you think of the alternative of calling llvm.gcroot on pointers in this
struct? This requires to change the verifier to support non-alloca pointers
in llvm.gcroot, but it makes the solution more general and cleaner: pointers
given to llvm.gcroot only point to objects in the heap.

I think that, originally, the purpose of the second argument of llvm.gcroot
was to emit static type information.

Nicolas


> It's all pretty simple really.
>
>
>>
>> Nicolas
>>
>>  On Fri, Sep 24, 2010 at 7:00 PM, Chris Lattner <clattner at
apple.com>wrote:
>>
>>>  On Sep 22, 2010, at 8:52 AM, Talin wrote:
>>> > I'm moving this thread to llvm-dev in the hopes of
reaching a wider
>>> audience.
>>> >
>>> > This patch relaxes the restriction on llvm.gcroot so that it
can work
>>> with non-pointer allocas. The only changes are to Verifier.cpp - it
appears
>>> from my testing that llvm.gcroot always worked fine with
non-pointer
>>> allocas, except that the verifier wouldn't allow it. I've
used this patch to
>>> build an efficient stack crawler (an alternative to shadow-stack
that uses
>>> only static constant data structures.)
>>> >
>>> > Here's a deal: If you accept this patch, I'll write up
an extensive
>>> tutorial on how to write a stack crawler like mine. (Actually,
it's already
>>> written, however without this patch the tutorial doesn't make
any sense.)
>>>
>>> Hi Talin,
>>>
>>> I don't think anyone is really using the GC support, other than
Nicolas
>>> in VMKit.  If he's ok with the change, I am too.  Please make
sure the dox
>>> stay up to date though.
>>>
>>> -Chris
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>>
>
>
> --
> -- Talin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100925/5ee82079/attachment.html>