[llvm-dev] (no subject)

[Philip Reames via llvm-dev]

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>