Displaying 7 results from an estimated 7 matches for "heapobject".
Did you mean:
heapobjects
2007 Aug 12
0
[LLVMdev] ocaml+llvm
...r return
The garbage collector uses this when walking the stack to find
live objects.
-- frame table example --
This program will create 3 call sites. 2 are not interesting, but
the other will have 1 live root:
example.ml:
let keeplive x = "";;
let heapobject = "hello " ^ "world" in
print_endline heapobject;
keeplive heapobject
The interesting call is print_endline heapobject. After the return
of this call, the root heapobject is still live, so the collector
must trace it. To instruct the runtime to do so, the ocaml
co...
2012 Feb 15
0
[LLVMdev] LLVM GHC Backend: Tables Next To Code
...iting a blog post about TNTC is beyond the time I have right now.
Sure, understandable. I'm surprised someone else hasn't already :)
> Here is some high level documentation of the layout of Heap objects in GHC:
>
> http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects#InfoTables
>
> With TNTC enabled we generate code for closures of this form:
>
> .text
> .align 8
> .long Main_main1_srt-(Main_main1_info)+0
> .long 0
> .quad 4294967299
> .quad 0
> .quad 270582939663
> .globl Main_main1_info
> .type Main_main1_info, @ob...
2012 Feb 15
2
[LLVMdev] LLVM GHC Backend: Tables Next To Code
...C is beyond the time I have right now.
>
> Sure, understandable. I'm surprised someone else hasn't already :)
>
>> Here is some high level documentation of the layout of Heap objects in GHC:
>>
>> http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects#InfoTables
>>
>> With TNTC enabled we generate code for closures of this form:
>>
>> .text
>> .align 8
>> .long Main_main1_srt-(Main_main1_info)+0
>> .long 0
>> .quad 4294967299
>> .quad 0
>> .quad 270582939663
>> .globl Mai...
2012 Feb 14
3
[LLVMdev] LLVM GHC Backend: Tables Next To Code
Hmm writing a blog post about TNTC is beyond the time I have right now.
Here is some high level documentation of the layout of Heap objects in GHC:
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects#InfoTables
With TNTC enabled we generate code for closures of this form:
.text
.align 8
.long Main_main1_srt-(Main_main1_info)+0
.long 0
.quad 4294967299
.quad 0
.quad 270582939663
.globl Main_main1_info
.type Main_main1_info, @object
Main_main1_info:
.Lc1Df:
leaq -8(%rbp),%rax
cmpq %r15...
2012 Feb 15
0
[LLVMdev] LLVM GHC Backend: Tables Next To Code
...TNTC is beyond the time I have right now.
>
> Sure, understandable. I'm surprised someone else hasn't already :)
>
>> Here is some high level documentation of the layout of Heap objects in GHC:
>>
>> http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects#InfoTables
>>
>> With TNTC enabled we generate code for closures of this form:
>>
>> .text
>> .align 8
>> .long Main_main1_srt-(Main_main1_info)+0
>> .long 0
>> .quad 4294967299
>> .quad 0
>> .quad...
2012 Feb 14
0
[LLVMdev] LLVM GHC Backend: Tables Next To Code
On Feb 13, 2012, at 6:49 AM, Sergiu Ivanov wrote:
> On behalf of GHC hackers, I would like to discuss the possibility of
> having a proper implementation of the tables-next-to-code optimisation
> in LLVM.
It would be great to have this. However, the design will be tricky. Is there anything that spells out how the TNTC optimization works at the actual machine instruction level? It
2012 Feb 13
3
[LLVMdev] LLVM GHC Backend: Tables Next To Code
Hello everyone,
On behalf of GHC hackers, I would like to discuss the possibility of
having a proper implementation of the tables-next-to-code optimisation
in LLVM.
Currently, the object code produced by all three GHC backends follows
the convention that the table with the metadata of a closure is
located immediately before the code of the closure. This makes it
possible to get to both the code