[llvm-dev] (no subject)

[Yafei Liu via llvm-dev]

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/616b4b82/attachment.html>