search for: garbagecollectionscheme

...rograms. It's been an interesting and educational process, to say the least, and I've run into quite a few things that might be useful to know for others tackling similar projects. I've compiled my notes on the subject here for posterity: https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme I'd be happy to field any questions about the adventure as well, although that probably belongs off-list. Thanks, - Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130802/a64d1f53/attachment.h...

I have a significant chunk of notes from my experience with garbage collector integration with LLVM that I'd be happy to contribute to this effort. The original notes live here: https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme I imagine it would be preferred if that document was formatted and edited to match the existing efforts; I'll try and start converting it over in the next several days and submit a pull req when I've got a finished chapter. I also have some miscellaneous notes from my other work on the E...

Hi Philip, Thanks for your great list of ideas for the document! I don't really have a scope for the document beyond: If it something that requires mapping from high-level to LLVM IR, I think it should go into the document. I started out using C++ examples because many people know C++. I am personally mostly an advocate of statically checked languages but I don't see that as a reason

...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 haven't had time to get much further than idle pondering of how I'd go about implementing relocation, but it seems to me like the existing read/write barrier intrinsics might be sufficient if abused properly by the front-end and lowered carefully. My operating hypothesis has bee...

...hibits certain classes of memory allocation/deallocation tricks. You can implement a copying GC (what the kids these days call relocating) without accurate roots. > > > I wrote up a bunch of my findings on the implementation of my GC here: https://code.google.com/p/epoch-language/wiki/GarbageCollectionScheme > Why aren't you just using the well-known Bartlett style of GC, which allows for relocation even in the presence of conservative roots (or accurate roots that don't allow relocation)? > > Frankly I haven't had time to get much further than idle pondering of how I'd go...

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