[llvm-dev] (no subject)

[Yafei Liu via llvm-dev]

Hi Philip, are there any C++ APIs to generate the llvm
statepoint instructions? I didn't found APIs similar to how to generate
gcroot instructions.

On Mon, Oct 21, 2019 at 2:03 PM Yafei Liu <yfliu at mobvoi.com> wrote:

> Thanks Philip,  I'll keep investigating.
>
> On Mon, Oct 21, 2019 at 9:52 AM Philip Reames <listmail at philipreames.com>
> wrote:
>
>> Correct, with a couple of nit picks.
>>
>> Relocation isn't an optimization the collector performs.  It's a key
>> primitive the collector is built upon.  Being unable to relocate is not an
>> allowed state.  (i.e. pinning can't be required by the compiler)
>>
>> When you talk about variables, that's true for the *source* language and
>> for the *abstract* machine before lowering.  After lowering from the
>> abstract machine, relocations are represented in the IR explicitly as an
>> entirely new set of defs.
>>
>> Philip
>> On 10/20/19 6:40 PM, Yafei Liu wrote:
>>
>> Correct me if I'm wrong:
>> Relocation in this conversation "relocation" means GC trying to move
>> objects in the heap for optimization (make the data more impact for bigger
>> room for example), this move is invisible to a programmer, and if a
>> compiler support to " relocate objects directly reachable from running
>> code", a variable (Foo foo) may points to a different address after a GC
>> happens, while a programmer could still use the name foo in the code as if
>> nothing happened.
>>
>> On Sun, Oct 20, 2019 at 4:35 AM Philip Reames via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Exactly this.  (As the person who wrote the line in question.)
>>> On 10/18/19 8:50 AM, Hiroshi Yamauchi via llvm-dev wrote:
>>>
>>> I think it's referring to a "moving" garbage collector (as opposed to a
>>> "non-moving" garbage collector that never moves/relocates objects.) The
>>> difference is that for a moving one, all pointers need to be tracked and
>>> potentially updated, whereas for a non-moving one, it's sufficient that at
>>> least one pointer to a live object is seen (when there may be other
>>> pointers to the same object elsewhere) for correctness.
>>>
>>> On Fri, Oct 18, 2019 at 2:12 AM Yafei Liu via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm investigating on integrating a gc to my llvm project, and when I
>>>> read this document <http://llvm.org/docs/Statepoints.html>, one
>>>> sentence confused me:
>>>>
>>>> However, for a collector which wishes to relocate objects directly
>>>> reachable from running code, a higher standard is required.
>>>>
>>>> I don't understand what the move "relocate objects directly reachable
>>>> from running code" trying to do.
>>>>
>>>> For my information, the concept "relocate" means the gc pointer
>>>> refereed to a new location of an object, for example:
>>>>
>>>> in Java:
>>>>
>>>> Foo foo = new Foo();
>>>>
>>>> foo = new Foo(); // ---> a relocation happens
>>>>
>>>> So can anyone explain what the "relocate objects directly reachable
>>>> from running code" trying to do?
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191021/f874a3ff/attachment.html>