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 <mailto: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 <mailto: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 <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto: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/20191020/5540410b/attachment.html>
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>
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>