search for: collectors

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

Hello All Does any know about some opensource multithread-compatible (or concurrent) garbage collector library, if possible suitable for LLVM? (I mean that I want several mutator threads; the collector can be stoptheworld or concurrent ....) H.Boehm's conservative GC is multithread compatible, but seems quite slow (allocation is about the time of a C malloc). And it is well known that

2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>: > I'm not sure the purpose of doing so—llvm::Collector (poorly named; > I'm open to suggestions) exists only in the compiler, not at runtime > in the compiled program. You should need access to it at runtime no > more than you might need access to an instance of llvm::TargetMachine. Maybe I don't understand the

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 Bartlett style of GC, which > allows for relocation even in the presence of conservative roots (or > accurate roots that don't allow relocation)? You've brou...

Forgive my top post but I hate Windows. J I am surprised you (Talin) say that "we know conservative collectors work" because my experience has very much been of them not working. Indeed, if you have 400Mb of allocated heap blocks on a 32-bit machine is there not a 10% chance of *each* random 32-bit int "pointing" into your heap, i.e. a false positive? I just did a simple test here (create an...

On May 1, 2009, at 1:27 PM, Basile STARYNKEVITCH wrote: > Hello All > > Does any know about some opensource multithread-compatible (or > concurrent) garbage collector library, if possible suitable for LLVM? In fact, yes! http://code.google.com/p/scarcity/ -Chris

...are sufficient. > In the paper cited above, the write barrier checks to see if the object being mutated has been traced; If it hasn't, then it records the values of all pointers contained in the object into a buffer - for which you need the location of the pointers. > In concurrent collectors—by which I mean those that run > asynchronously of the mutator—write barriers may be used to mark the > written object pointer. Even byte arrays as you describe require an > object header in which to store mark bits, else the collector cannot > know whether the object has been m...

On Jul 26, 2008, at 12:14, Simon Ask Ulsnes wrote: > 2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>: >> I'm not sure the purpose of doing so—llvm::Collector (poorly named; >> I'm open to suggestions) exists only in the compiler, not at >> runtime in the compiled program. You should need access to it at >> runtime no more than you might need

Hey, I am a bit confused about the CollectorRegistry. I am attempting to write a garbage collector for LLVM, and the tiny example in the docs at http://llvm.org/releases/2.3/docs/GarbageCollection.html gives this line: CollectorRegistry::Add<MyCollector> X("mygc", "My bespoke garbage collector."); My question is now: Am I supposed to instantiate my collector

...You only have to copy pointers. If you've got a struct, you only need > to keep a root for the pointer member(s) of that struct. > Here's another way to think about the issue: Compare this whole approach to stack roots to that of a conservative collector. Since we know conservative collectors work, the whole reason for making an accurate collector in the first place is efficiency, right? If we couldn't make an accurate collector that was more efficient than a conservative collector, then no one would bother because it's such a pain. However, looking strictly at stack frames, a...

Basile STARYNKEVITCH wrote: > Does any know about some opensource multithread-compatible (or > concurrent) garbage collector library, if possible suitable for LLVM? > > (I mean that I want several mutator threads; the collector can be > stoptheworld or concurrent ....) > > H.Boehm's conservative GC is multithread compatible, but seems quite > slow (allocation is

...e a strong requirement for a high-performance LLVM-compatible collector.) The last time I looked, the LLVM support for GC is fairly austere, consisting of (a) the bare minimum set of low-level intrinsics needed to integrate a collector with a runtime environment, and (b) a couple of example of collectors, neither of which AFAIK take full advantage of the low-level intrinsics to get optimal performance. The IR-level intrinsics themselves don't much help you *write* a GC, so much as to integrate one with LLVM. What is provided is essentially a mechanism for walking the stack, and a means to i...

Gordon Henriksen wrote: > On 2007-09-15, at 23:55, Talin wrote: > >> Gordon Henriksen wrote: >> >>> Can you be more specific the algorithm for which you need type >>> metadata in a write barrier? No algorithms I am aware of perform any >>> tracing from a write barrier. >> >> This one does: >> >>

...iently performance > sensitive, you can later investigate implementing a custom Collector > plugin. OK. This is helpful in trying to understand what the Collector plugin is. So is it correct then that the Collector plugin is the GC's view into the backend? In other words, most garbage collectors have to have some knowledge of how the runtime stack is actually laid out. ShadowStack skirts around this issue by maintaining a "shadow" stack, so when the GC needs info about the runtime stack, ShadowStack instead provides info about the "shadow" stack. But most collector plug...

Hello, i want to implement a common lisp subset using llvm for fun. This requires the use of a garbage collector. I read the docs, but many things are still unclear to me. 1. how are collectors supposed to find all living objects? there is llvm.gcroot for marking objects on the stack,but how do collectors crawl heap objects? I did not see a way to provide custom mark functions. Are collectors supposed to rely on the type informations provided by llvm? 2. what about gcreading and gcwrit...

Hi gang, I feel like I''m missing something fundamental here… I''ve got the following: class snmp::rhel::rh5enable { $collector = [''10.0.0.1'', ''10.0.0.2''] define add_snmp_hosts_allow ($ip) { exec { "hosts_allow_$ip": command => "/bin/echo \"snmpd : $ip : ALLOW\" >>/etc/hosts.allow",

I'm still (slowly) working on the project of creating a concurrent garbage collector that works with LLVM. I want to ask a little bit more about object tags and write barriers and so on. Let's start with the assumption that a particular language does not use per-object type tags. The code generator knows the types of all objects, however, and can pass along that type information to

...tracing from a write barrier. Write barriers are commonly used to record references from old- generation objects to new-generation ones, either by recording the referencing object, the referencing field, or using a card table. For these purposes, the addresses are sufficient. In concurrent collectors—by which I mean those that run asynchronously of the mutator—write barriers may be used to mark the written object pointer. Even byte arrays as you describe require an object header in which to store mark bits, else the collector cannot know whether the object has been marked (mark-sweep co...

2008/7/24 Gordon Henriksen <gordonhenriksen at me.com>: >> OK, so for instance if I wanted to be able to use the GC from a C >> frontend (presumably by using llvm_gc_allocate?), do the C functions >> need this attribute as well? > > Yes. I forgot I still needed an answer to my original question. :-P So, I have to implement llvm_gc_initialize, llvm_gc_allocate, and

On Tue, Sep 21, 2010 at 8:20 PM, Talin <viridia at gmail.com> wrote: > On Mon, Sep 20, 2010 at 3:16 PM, Talin <viridia at gmail.com> wrote: >> >> So I've managed to get my stack crawler working and passing its unit tests >> - this is the one I've been working on as an alternative to shadow-stack: it >> uses only static constant data structures (no