[llvm-dev] (no subject)
Yafei Liu via llvm-dev
llvm-dev at lists.llvm.org
Sun Oct 20 23:03:59 PDT 2019
Thanks Philip, I'll keep investigating.
On Mon, Oct 21, 2019 at 9:52 AM Philip Reames <listmail at philipreames.com>
> 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.
> 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
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev