similar to: [LLVMdev] GC heap implementation

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 Terence, On 2008-04-20, at 20:08, Terence Parr wrote: > I've exhausted what I can do on my own to make a GC example bind > (usual googling, reading, playing, looking at source). I can't find > the shadow collector lib or perhaps the -l options needed to link my > sample (not even to point where I'm figuring out GC actually as I > can't link). The shadow

On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote: > The shadow stack walker is in the runtime directory with the semispace > heap example. The runtime directory is built to LLVM IR using llvm- > gcc. So it's skipped unless you configure llvm with llvm-gcc support. doh! That's how I missed the binary. thanks! > Since the semispace heap doesn't actually work (it's

Hi I'm using a GC that's pretty similar to the OCaml one. It records stack locations using llvm.gcroot, and dumps out a frametable describing the live stack offsets so that the GC runtime can walk them as required. I'm on 2.3, not svn head. I'm having some trouble with pointers being cached in registers across function calls (at least x86 backend, haven't tried others yet).

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 all, In order to support linking AsmWriter separately from CodeGen, the Collector class (a CodeGen component) had to be decoupled from the AsmWriter interface. This required moving the beginAssembly and endAssembly methods to a separate abstract base class. If you had overridden these methods, your class may compile successfully but fail at runtime with a message of the form:

On Mon, Apr 21, 2008 at 8:13 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > > Hi Terence, > > > I think you're getting hung up on the details of the shadow stack collector. > The shadow stack is a GC that is possible within this framework, but of > course could be implemented without any special support. Its presence is > more misleading than anything

> 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

The virtual machine I'm implementing allocates objects on the heap using Boehm's garbage collector. I currently have an interpreter working for my language, and I'm working on a JIT that will compile some of the functions that would otherwise get interpreted. What I'm wondering is whether or not I need to perform special adjustments for the GC to work properly. My understanding is

Chris Lattner wrote: > On Feb 26, 2009, at 12:02 AM, Talin wrote: > >> With the increasing >> number of LLVM-based VMs and other projects, I suspect that the desire >> for more comprehensive garbage collection support in LLVM is only >> going >> to increase. >> > > Absolutely! > > >> Part of the reason why there isn't

On Thu, 28 Oct 2004, Tom Brown wrote: > We have a few questions about the current state of GC. Ok. :) > We decided to start (and finish?) our work by finishing SemiSpace. Sounds good. > process_pointer is meant to move objects from CurSpace to OtherSpace. > How can it find pointers to a moved object? This is entirely up to you, as you're basically implementing the semispace

Hi Terence, I think you're getting hung up on the details of the shadow stack collector. The shadow stack is a GC that is possible within this framework, but of course could be implemented without any special support. Its presence is more misleading than anything else. Taking a step back, the concepts are: llvm.gcroot instructs the code generator --> My GC needs to be able to

Dear all, Me and the Garbage Collector doesn't understand each other... I'm on R-1.0.1 (I have requested an upgrade to the right local people), an osf1 system with an alphaev6 CPU. I have fair amounts of memory to use, but it seems to be used up pretty fast nevertheless. I'm now trying to see what the garbage collector does, I have inserted a gc(v=T) call at a spot in my code. I

On Tuesday 16 June 2009 07:37:32 Talin wrote: > A while back there was a discussion thread about whether an accurate, > concurrent garbage collector could be "generic" in the sense of being > able to support multiple different languages efficiently. After having > done some work on this, I now believe that this is the case - using C++ > policy-based design principles, you

On Apr 20, 2008, at 6:52 PM, Gordon Henriksen wrote: > On 2008-04-20, at 21:05, Terence Parr wrote: > >> On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote: >> >>> Since the semispace heap doesn't actually work (it's an example, >>> at best), I suggest you simply copy the stack visitor into your >>> project; it's only a dozen lines of

Howdy do LLVM folks! I've exhausted what I can do on my own to make a GC example bind (usual googling, reading, playing, looking at source). I can't find the shadow collector lib or perhaps the -l options needed to link my sample (not even to point where I'm figuring out GC actually as I can't link). Not sure this IR is correct but here is what I've been playing

On Feb 26, 2009, at 12:02 AM, Talin wrote: > With the increasing > number of LLVM-based VMs and other projects, I suspect that the desire > for more comprehensive garbage collection support in LLVM is only > going > to increase. Absolutely! > Part of the reason why there isn't more direct support for GC is the > theory that there is no such thing as a

On 2008-04-20, at 21:05, Terence Parr wrote: > On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote: > >> Since the semispace heap doesn't actually work (it's an example, at >> best), I suggest you simply copy the stack visitor into your >> project; it's only a dozen lines of code or so. > > > Ok, copying; can't find ShadowStackEntry though.

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

On Mon, 19 Jul 2004, Tobias Nurmiranta wrote: > Regarding llvm.gcroot, do I have to allocate stack-space for all > pointers in a function? Right now I mostly use SSA-variables, and let > llvm's register allocation allocate stack-space when needed. Yes. This reflects the fact that the GC can move objects (to compact the heap) at unpredictable times. > Also, what happens when I