[llvm-dev] (no subject)

Hiroshi Yamauchi via llvm-dev llvm-dev at lists.llvm.org
Fri Oct 18 08:50:15 PDT 2019


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191018/8c0e614c/attachment.html>


More information about the llvm-dev mailing list