search for: collectormetadata

On Mon, 2008-04-28 at 21:39 -0500, Lane Schwartz wrote: > On Mon, Apr 28, 2008 at 8:31 PM, Gordon Henriksen > <gordonhenriksen at mac.com> wrote: > > On 2008-04-28, at 21:19, Lane Schwartz wrote: > > > > > On Mon, Apr 28, 2008 at 2:13 PM, Gordon Henriksen <gordonhenriksen at mac.com > > >> stack and discover the return address of each call frame.

On Mon, Apr 28, 2008 at 8:31 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On 2008-04-28, at 21:19, Lane Schwartz wrote: > > > On Mon, Apr 28, 2008 at 2:13 PM, Gordon Henriksen <gordonhenriksen at mac.com > > > wrote: > > > >>> If so, then a Collector plugin would need to have info about every > >>> supported backend

...y be clearer. In particular, Collector was confusing to implementors. Several thought that this compile-time class was the place to implement their runtime GC heap. Of course, it doesn't even exist at runtime. Specifically, the renames are: Collector -> GCStrategy CollectorMetadata -> GCFunctionInfo CollectorModuleMetadata -> GCModuleInfo CollectorRegistry -> GCRegistry Function::getCollector -> getGC [setGC, hasGC, clearGC] Several accessors and nested types have also been renamed to be consistent. These changes should be obvious. Pleas...

...a variable in GC space, I'll store a char at the beginning of the memory for that variable that simply indicates the type (and I'll be able to infer the size from the type). Given that, I assume I won't ever need use the collector metadata (in @llvm.gcroot, llvm_cg_walk_gcroots, or via CollectorMetadata). Is that right? What does it mean for the plugin to compute a stack map? When are the methods of the plugin called? Who is responsible for calling them? When is the constructor of the plugin called? What is the relationship between the plugin and the GC runtime? In the GC docs, section "...

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

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