[llvm-dev] Non-relocating GC with liveness tracking

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] Non-relocating GC with liveness tracking

Alberto Barbaro via llvm-dev
Hi Team,
I'm working on a new pure functional language and I'm trying to add GC support for that.

Because all vars are immutable, the IR that my frontend generates are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. 

If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR values into the gcroot, which seems convoluted. 

I found using stack map / statepoints very plausible here, because it only needs all live vars without saving it to a corresponding gcroot, and can track liveness at every call point.

However, this seems still marked as experimental, and doesn't support exception handling (which is a requirement for my language). And because my language uses return barriar (http://lists.llvm.org/pipermail/llvm-dev/2017-August/116291.html), I'm already using a new intrinsic that returns a token type for calls so I can have multiple return paths that retrieves the actual result, and currently it doesn't work with gc.statepoint.

I wanna check the status of statepoint GC: Is it still actively developed? is there any plan to fix the exception handling path? Or should I continue to use the gcroot intrinsic? Change my new multi-return intrinsic to support statepoint?

I'm also thinking using a non-relocating GC with stackmap because relocating is currently optional for me: all live roots are passed to call site as operand bundle, so codegen can emit the stack map, and my new intrinsic for multiple return paths can also work with that.

Any advise will be welcome.

Thanks

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Non-relocating GC with liveness tracking

Alberto Barbaro via llvm-dev
I remember Haskell GHC using LLVM as its backend. Haskell is pure functional language also. A little google search shows it supports garbage collection, too. Looking into GHC's implementation might be help.

2017-12-09 5:29 GMT+08:00 Chuan Qiu via llvm-dev <[hidden email]>:
Hi Team,
I'm working on a new pure functional language and I'm trying to add GC support for that.

Because all vars are immutable, the IR that my frontend generates are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. 

If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR values into the gcroot, which seems convoluted. 

I found using stack map / statepoints very plausible here, because it only needs all live vars without saving it to a corresponding gcroot, and can track liveness at every call point.

However, this seems still marked as experimental, and doesn't support exception handling (which is a requirement for my language). And because my language uses return barriar (http://lists.llvm.org/pipermail/llvm-dev/2017-August/116291.html), I'm already using a new intrinsic that returns a token type for calls so I can have multiple return paths that retrieves the actual result, and currently it doesn't work with gc.statepoint.

I wanna check the status of statepoint GC: Is it still actively developed? is there any plan to fix the exception handling path? Or should I continue to use the gcroot intrinsic? Change my new multi-return intrinsic to support statepoint?

I'm also thinking using a non-relocating GC with stackmap because relocating is currently optional for me: all live roots are passed to call site as operand bundle, so codegen can emit the stack map, and my new intrinsic for multiple return paths can also work with that.

Any advise will be welcome.

Thanks

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev




--
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Non-relocating GC with liveness tracking

Alberto Barbaro via llvm-dev
In reply to this post by Alberto Barbaro via llvm-dev
+CC Philip Reames and Anna Thomas from Azul Systems

On Fri, Dec 8, 2017 at 1:29 PM, Chuan Qiu via llvm-dev
<[hidden email]> wrote:

> Hi Team,
> I'm working on a new pure functional language and I'm trying to add GC
> support for that.
>
> Because all vars are immutable, the IR that my frontend generates are all
> register based, i.e. no alloca, and no readmem, writemem unless
> accessing/constructing structs.
>
> If I use the traditional GC with gcroot intrinsic, it will need to emit more
> code for liveness tracking, storing the IR values into the gcroot, which
> seems convoluted.
>
> I found using stack map / statepoints very plausible here, because it only
> needs all live vars without saving it to a corresponding gcroot, and can
> track liveness at every call point.
>
> However, this seems still marked as experimental, and doesn't support
> exception handling (which is a requirement for my language). And because my
> language uses return barriar
> (http://lists.llvm.org/pipermail/llvm-dev/2017-August/116291.html), I'm
> already using a new intrinsic that returns a token type for calls so I can
> have multiple return paths that retrieves the actual result, and currently
> it doesn't work with gc.statepoint.
>
> I wanna check the status of statepoint GC: Is it still actively developed?
> is there any plan to fix the exception handling path? Or should I continue
> to use the gcroot intrinsic? Change my new multi-return intrinsic to support
> statepoint?
>
> I'm also thinking using a non-relocating GC with stackmap because relocating
> is currently optional for me: all live roots are passed to call site as
> operand bundle, so codegen can emit the stack map, and my new intrinsic for
> multiple return paths can also work with that.
>
> Any advise will be welcome.
>
> Thanks
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Non-relocating GC with liveness tracking

Alberto Barbaro via llvm-dev
In reply to this post by Alberto Barbaro via llvm-dev

Returning to an ancient thread.  Sorry for the prolonged lack of response.

gc.statepoint is supported and actively developed.  The only production usage of LLVM's GC support I'm aware of is using gc.statepoint.  I recommend you use gc.statepoint, not gcroot.

I recently made a set of documentation edits which may provide some useful guidance for your non-relocating collector design.  I'd be curious to know what you've settled on and what progress you've made.

Philip


On 12/8/17 1:29 PM, Chuan Qiu via llvm-dev wrote:
Hi Team,
I'm working on a new pure functional language and I'm trying to add GC support for that.

Because all vars are immutable, the IR that my frontend generates are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. 

If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR values into the gcroot, which seems convoluted. 

I found using stack map / statepoints very plausible here, because it only needs all live vars without saving it to a corresponding gcroot, and can track liveness at every call point.

However, this seems still marked as experimental, and doesn't support exception handling (which is a requirement for my language). And because my language uses return barriar (http://lists.llvm.org/pipermail/llvm-dev/2017-August/116291.html), I'm already using a new intrinsic that returns a token type for calls so I can have multiple return paths that retrieves the actual result, and currently it doesn't work with gc.statepoint.

I wanna check the status of statepoint GC: Is it still actively developed? is there any plan to fix the exception handling path? Or should I continue to use the gcroot intrinsic? Change my new multi-return intrinsic to support statepoint?

I'm also thinking using a non-relocating GC with stackmap because relocating is currently optional for me: all live roots are passed to call site as operand bundle, so codegen can emit the stack map, and my new intrinsic for multiple return paths can also work with that.

Any advise will be welcome.

Thanks

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Non-relocating GC with liveness tracking

Alberto Barbaro via llvm-dev
Thanks for reviving this.
I completely forgot the details but I resolved this problem. Looking though the code, seems I forked RewriteStatepointsForGC pass, and change it to adding 'gc-livevars' bundle to the call/invoke inst after finding the livevars, instead of changing it to StatepointCall intrinsic.

On Wed, Nov 14, 2018 at 11:48 AM Philip Reames <[hidden email]> wrote:

Returning to an ancient thread.  Sorry for the prolonged lack of response.

gc.statepoint is supported and actively developed.  The only production usage of LLVM's GC support I'm aware of is using gc.statepoint.  I recommend you use gc.statepoint, not gcroot.

I recently made a set of documentation edits which may provide some useful guidance for your non-relocating collector design.  I'd be curious to know what you've settled on and what progress you've made.

Philip


On 12/8/17 1:29 PM, Chuan Qiu via llvm-dev wrote:
Hi Team,
I'm working on a new pure functional language and I'm trying to add GC support for that.

Because all vars are immutable, the IR that my frontend generates are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. 

If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR values into the gcroot, which seems convoluted. 

I found using stack map / statepoints very plausible here, because it only needs all live vars without saving it to a corresponding gcroot, and can track liveness at every call point.

However, this seems still marked as experimental, and doesn't support exception handling (which is a requirement for my language). And because my language uses return barriar (http://lists.llvm.org/pipermail/llvm-dev/2017-August/116291.html), I'm already using a new intrinsic that returns a token type for calls so I can have multiple return paths that retrieves the actual result, and currently it doesn't work with gc.statepoint.

I wanna check the status of statepoint GC: Is it still actively developed? is there any plan to fix the exception handling path? Or should I continue to use the gcroot intrinsic? Change my new multi-return intrinsic to support statepoint?

I'm also thinking using a non-relocating GC with stackmap because relocating is currently optional for me: all live roots are passed to call site as operand bundle, so codegen can emit the stack map, and my new intrinsic for multiple return paths can also work with that.

Any advise will be welcome.

Thanks

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Non-relocating GC with liveness tracking

Alberto Barbaro via llvm-dev

This sounds like an incomplete description since codegen would have no knowledge of the new bundle type and discard them.  Would you be willing to share your patches?  I'd be curious to see there approach you took, maybe there's something analogous we can do upstream.

Philip

On 11/19/18 12:01 AM, Chuan Qiu wrote:
Thanks for reviving this.
I completely forgot the details but I resolved this problem. Looking though the code, seems I forked RewriteStatepointsForGC pass, and change it to adding 'gc-livevars' bundle to the call/invoke inst after finding the livevars, instead of changing it to StatepointCall intrinsic.

On Wed, Nov 14, 2018 at 11:48 AM Philip Reames <[hidden email]> wrote:

Returning to an ancient thread.  Sorry for the prolonged lack of response.

gc.statepoint is supported and actively developed.  The only production usage of LLVM's GC support I'm aware of is using gc.statepoint.  I recommend you use gc.statepoint, not gcroot.

I recently made a set of documentation edits which may provide some useful guidance for your non-relocating collector design.  I'd be curious to know what you've settled on and what progress you've made.

Philip


On 12/8/17 1:29 PM, Chuan Qiu via llvm-dev wrote:
Hi Team,
I'm working on a new pure functional language and I'm trying to add GC support for that.

Because all vars are immutable, the IR that my frontend generates are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. 

If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR values into the gcroot, which seems convoluted. 

I found using stack map / statepoints very plausible here, because it only needs all live vars without saving it to a corresponding gcroot, and can track liveness at every call point.

However, this seems still marked as experimental, and doesn't support exception handling (which is a requirement for my language). And because my language uses return barriar (http://lists.llvm.org/pipermail/llvm-dev/2017-August/116291.html), I'm already using a new intrinsic that returns a token type for calls so I can have multiple return paths that retrieves the actual result, and currently it doesn't work with gc.statepoint.

I wanna check the status of statepoint GC: Is it still actively developed? is there any plan to fix the exception handling path? Or should I continue to use the gcroot intrinsic? Change my new multi-return intrinsic to support statepoint?

I'm also thinking using a non-relocating GC with stackmap because relocating is currently optional for me: all live roots are passed to call site as operand bundle, so codegen can emit the stack map, and my new intrinsic for multiple return paths can also work with that.

Any advise will be welcome.

Thanks

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Non-relocating GC with liveness tracking

Alberto Barbaro via llvm-dev

Actually, are you possibly using "bundle" to refer to a set of arguments to the statepoint?  We've since introduced "operand bundles" which is what I assumed you meant. 

On 11/25/18 6:56 PM, Philip Reames wrote:

This sounds like an incomplete description since codegen would have no knowledge of the new bundle type and discard them.  Would you be willing to share your patches?  I'd be curious to see there approach you took, maybe there's something analogous we can do upstream.

Philip

On 11/19/18 12:01 AM, Chuan Qiu wrote:
Thanks for reviving this.
I completely forgot the details but I resolved this problem. Looking though the code, seems I forked RewriteStatepointsForGC pass, and change it to adding 'gc-livevars' bundle to the call/invoke inst after finding the livevars, instead of changing it to StatepointCall intrinsic.

On Wed, Nov 14, 2018 at 11:48 AM Philip Reames <[hidden email]> wrote:

Returning to an ancient thread.  Sorry for the prolonged lack of response.

gc.statepoint is supported and actively developed.  The only production usage of LLVM's GC support I'm aware of is using gc.statepoint.  I recommend you use gc.statepoint, not gcroot.

I recently made a set of documentation edits which may provide some useful guidance for your non-relocating collector design.  I'd be curious to know what you've settled on and what progress you've made.

Philip


On 12/8/17 1:29 PM, Chuan Qiu via llvm-dev wrote:
Hi Team,
I'm working on a new pure functional language and I'm trying to add GC support for that.

Because all vars are immutable, the IR that my frontend generates are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. 

If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR values into the gcroot, which seems convoluted. 

I found using stack map / statepoints very plausible here, because it only needs all live vars without saving it to a corresponding gcroot, and can track liveness at every call point.

However, this seems still marked as experimental, and doesn't support exception handling (which is a requirement for my language). And because my language uses return barriar (http://lists.llvm.org/pipermail/llvm-dev/2017-August/116291.html), I'm already using a new intrinsic that returns a token type for calls so I can have multiple return paths that retrieves the actual result, and currently it doesn't work with gc.statepoint.

I wanna check the status of statepoint GC: Is it still actively developed? is there any plan to fix the exception handling path? Or should I continue to use the gcroot intrinsic? Change my new multi-return intrinsic to support statepoint?

I'm also thinking using a non-relocating GC with stackmap because relocating is currently optional for me: all live roots are passed to call site as operand bundle, so codegen can emit the stack map, and my new intrinsic for multiple return paths can also work with that.

Any advise will be welcome.

Thanks

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Non-relocating GC with liveness tracking

Alberto Barbaro via llvm-dev
https://github.com/eagleonhill/qlang-llvm/commit/e360bc7cd937a3c229b6f5fec3c06f961ab47c51 This is the patch in CodeGen. Actually I completely forgot I did that..

The change in GCRootPass is not done in the LLVM fork and have some coupling with my frontend, so it's not ready to publish yet.

On Sun, Nov 25, 2018 at 6:57 PM Philip Reames <[hidden email]> wrote:

Actually, are you possibly using "bundle" to refer to a set of arguments to the statepoint?  We've since introduced "operand bundles" which is what I assumed you meant. 

On 11/25/18 6:56 PM, Philip Reames wrote:

This sounds like an incomplete description since codegen would have no knowledge of the new bundle type and discard them.  Would you be willing to share your patches?  I'd be curious to see there approach you took, maybe there's something analogous we can do upstream.

Philip

On 11/19/18 12:01 AM, Chuan Qiu wrote:
Thanks for reviving this.
I completely forgot the details but I resolved this problem. Looking though the code, seems I forked RewriteStatepointsForGC pass, and change it to adding 'gc-livevars' bundle to the call/invoke inst after finding the livevars, instead of changing it to StatepointCall intrinsic.

On Wed, Nov 14, 2018 at 11:48 AM Philip Reames <[hidden email]> wrote:

Returning to an ancient thread.  Sorry for the prolonged lack of response.

gc.statepoint is supported and actively developed.  The only production usage of LLVM's GC support I'm aware of is using gc.statepoint.  I recommend you use gc.statepoint, not gcroot.

I recently made a set of documentation edits which may provide some useful guidance for your non-relocating collector design.  I'd be curious to know what you've settled on and what progress you've made.

Philip


On 12/8/17 1:29 PM, Chuan Qiu via llvm-dev wrote:
Hi Team,
I'm working on a new pure functional language and I'm trying to add GC support for that.

Because all vars are immutable, the IR that my frontend generates are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. 

If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR values into the gcroot, which seems convoluted. 

I found using stack map / statepoints very plausible here, because it only needs all live vars without saving it to a corresponding gcroot, and can track liveness at every call point.

However, this seems still marked as experimental, and doesn't support exception handling (which is a requirement for my language). And because my language uses return barriar (http://lists.llvm.org/pipermail/llvm-dev/2017-August/116291.html), I'm already using a new intrinsic that returns a token type for calls so I can have multiple return paths that retrieves the actual result, and currently it doesn't work with gc.statepoint.

I wanna check the status of statepoint GC: Is it still actively developed? is there any plan to fix the exception handling path? Or should I continue to use the gcroot intrinsic? Change my new multi-return intrinsic to support statepoint?

I'm also thinking using a non-relocating GC with stackmap because relocating is currently optional for me: all live roots are passed to call site as operand bundle, so codegen can emit the stack map, and my new intrinsic for multiple return paths can also work with that.

Any advise will be welcome.

Thanks

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev