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

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 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

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

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

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

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

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,

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 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 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

With regard to Bartlett-style collectors, they are also used in CMUCL/SBCL, OpenDylan, and various products based on Ravenbrook's Memory Pool System. Also, while Mono doesn't use a Bartlett-style collector, it does support pinning objects referenced from ambiguous stack roots, in an otherwise copying collector. While ITA has expressed concerns with SBCL's GC, they seem to involve the

As I've mentioned on the mailing list a couple of times over the last few months, we've been working on an approach for supporting precise fully relocating garbage collection in LLVM. I am happy to announce that we now have a version of the code available for public view and discussion. https://github.com/AzulSystems/llvm-late-safepoint-placement

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

Hi, Sanjoy, On 2015-11-16 23:27, Sanjoy Das wrote: > Hi Vlad, > > vlad via llvm-dev wrote: >>> Vlad, >>> >>> My initial impression is that you've stumbled across a bug. I suspect >>> that we - the only active users of the deopt info in the statepoint I >>> know of - have been inverting the meaning of Direct and Indirect >>>

Sorry to reply to myself here, but I had an idea regarding "issue #2" -- possibly what makes the most sense for those clients/targets is to pull the pointer difference computation/reapplication into RS4GC itself -- it could have a pass just before or after rematerialization, which runs based on a configuration flag (eventually to be driven by GCStrategy), which performs rewrites like

For anyone following along on ToT using the gc.statepoint mechanism, you should know that ToT is currently not able to express arbitrary exceptional control flow and relocations along exceptional edges. This is a direct result of moving the gc.statepoint representation to using a token type landingpad. Essentially, we have a design inconsistency where we expect to be able to

Thanks, I think that's a useful way to look at it (though if I wanted to bikeshed I'd suggest the name "DoubleIndirect" as a bit more precise than "VeryIndirect"). An aspect of it that I'm still puzzling over is that my target runtime (at least in its current form) doesn't have a way to represent/process a "VeryIndirect" pointer. So I'd like to

> Vlad, > > My initial impression is that you've stumbled across a bug. I suspect > that we - the only active users of the deopt info in the statepoint I > know of - have been inverting the meaning of Direct and Indirect > throughout our code. (i.e. we're consistent, but swapped on the > documented meaning) I've asked Sanjoy to confirm that, and if he >

I'm moving this to a different thread. I think the newly proposed intrinsic definitions and their current implementation are valuable regardless of how it gets tied into GC... On Oct 22, 2013, at 6:24 PM, Philip R <listmail at philipreames.com> wrote: > Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support