similar to: [LLVMdev] Interfacing llvm with a precise, relocating GC

On 10/26/13 7:40 AM, Filip Pizlo wrote: > You can implement a copying GC (what the kids these days call > relocating) without accurate roots. I use "relocating" to brush over the distinction between "copying" and "compacting" collectors. For the purposes of our discussions, the two are interchangeable though. > Why aren't you just using the well-known

> On Oct 26, 2013, at 12:37 AM, Michael Lewis <don.apoch at gmail.com> wrote: > > I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. You can implement a copying GC (what the kids these days

On 24 October 2013 17:32, Sanjoy Das <sanjoy at azulsystems.com> wrote: > Hello llvm-dev! > > My colleages and I are currently evaluating llvm's suitability as a > JIT compiler interfacing with a precise, relocating garbage collector. > While we couldn't find code or writeups that deal with the issues > specific to this design goal, it is entirely possible that we

On 10/24/13 2:50 PM, Rafael Espíndola wrote: > On 24 October 2013 17:32, Sanjoy Das <sanjoy at azulsystems.com> wrote: >> Hello llvm-dev! >> >> My colleages and I are currently evaluating llvm's suitability as a >> JIT compiler interfacing with a precise, relocating garbage collector. >> While we couldn't find code or writeups that deal with the

On Oct 24, 2013, at 2:50 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 24 October 2013 17:32, Sanjoy Das <sanjoy at azulsystems.com> wrote: >> Hello llvm-dev! >> >> My colleages and I are currently evaluating llvm's suitability as a >> JIT compiler interfacing with a precise, relocating garbage collector. >> While we

Hello llvm-dev! My colleages and I are currently evaluating llvm's suitability as a JIT compiler interfacing with a precise, relocating garbage collector. While we couldn't find code or writeups that deal with the issues specific to this design goal, it is entirely possible that we may have missed something; we would appreciate references to relevant code or writeups that people on this

I'm also highly interested in relocating-GC support from LLVM. Up until now my GC implementation has been non-relocating which is obviously kind of a bummer given that it inhibits certain classes of memory allocation/deallocation tricks. I wrote up a bunch of my findings on the implementation of my GC here: https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme Frankly I

Hi Talin, Thank you for your response! Since you mention that you don't implement derived pointers, I'm a little confused about how your approach solves the issue I brought up. It seems to me that unless you plan on pinning some objects, support for derived pointers isn't optional. I'm not talking about derived pointers that the front-end introduces (which can be tracked) but

On Fri, Oct 25, 2013 at 8:35 PM, Philip Reames <listmail at philipreames.com>wrote: > On 10/25/13 1:10 PM, Ben Karel wrote: > > > > > On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com>wrote: > >> Hi Rafael, Andrew, >> >> Thank you for the prompt reply. >> >> One approach we've been considering involves

On 10/25/13 1:10 PM, Ben Karel wrote: > > > > On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com > <mailto:sanjoy at azulsystems.com>> wrote: > > Hi Rafael, Andrew, > > Thank you for the prompt reply. > > One approach we've been considering involves representing the > constraint "pointers to heap objects

Sanjoy: This document which I wrote several years ago may be of some use to you: Building a Stack Crawler in LLVM<https://docs.google.com/document/d/1-ws0KYo47S0CgqpwkjfWDBJ8wFhW_0UYKxPIJ0TyKrQ/edit?usp=sharing&authkey=COD8_LcL> I have successfully implemented a copying collector using LLVM. I did not implement support for interior pointers, however I have a number of ideas on how to

Hi Rafael, Andrew, Thank you for the prompt reply. One approach we've been considering involves representing the constraint "pointers to heap objects are invalidated at every safepoint" somehow in the IR itself. So, if %a and %b are values the GC is interested in, the safepoint at the back-edge of a loop might look like: ; <label>: body %a = phi i32 [ %a.relocated,

On Thu, Oct 24, 2013 at 6:42 PM, Sanjoy Das <sanjoy at azulsystems.com> wrote: > Hi Rafael, Andrew, > > Thank you for the prompt reply. > > One approach we've been considering involves representing the > constraint "pointers to heap objects are invalidated at every > safepoint" somehow in the IR itself. So, if %a and %b are values the > GC is

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

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 <listmail at philipreames.com>

Well, nothing has changed in the issues that I brought up earlier, except that I can confirm core dumps in non-threaded lisps as well (CLISP), using svn version 37840 (this morning, Seattle time) for R-2-3-patches. I've not tried Thomas' suggested fixes, as I'm hesistant to go down the road of fixing R in such a way that would require constant patching. (so for those counting,

Hi, My collector supports only base pointers as stack roots. This wasn't a problem until I tried to run some optimizations before RS4GC, which introduced (interior) derived pointers. The statepoint documentation mentions that these collectors exist, but doesn't mention whether and how this is currently supported. What could I do to make it work? -Manuel

Yes, indeed! The SBCL lisp compiler (not llvm based) used to emit functions which would return either via ret to the usual instruction after the call, or else load the return-address from the stack, then jump 2 bytes later (which would skip over either a nop or a short jmp at original target location). Which one it used depended upon whether the function was doing a multi-valued return (in which

Hi all, I've been using the llvm.gcroot intrinsic combined with the generated machine stack maps to attempt to do precise GC without the use of a shadow stack. (This is all research work on a novel language so I have no existing system to compare against, for the record.) Most of my test suite is working and tracing stack roots correctly. However, there seem to be some scenarios where the

> From: Wensui Liu <liuwensui at gmail.com> > Just curious how xlispstat is used in the industry and what's it strengthen > compared with other computing languages such as R or matlab? Almost not at all, though there are a few holdouts. On a related note, I've been doing some interesting things with a branch of LispStat for CommonLisp. It'll be more interesting when