Re: Getting rid of HEAP_ALLOCED

On 24/08/13 23:08, Edward Z. Yang wrote:
Part of the resource limits work needs to access the bdescr for a thunk when it is entered. Of course, right now, this needs to go through HEAP_ALLOCED; I imagine this would way to slow to put into the generated code. So I happened across this page describing some previous efforts to get rid of the HEAP_ALLOCED check:
http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapAlloced
So I'm currently implementing method 2, and I'm wondering what the best way to setup the indirection table might be: maybe some sort of null-terminated array? What's the proper way for the linker to figure out where the indirection table lives?
Getting rid of HEAP_ALLOCED would be wonderful! And I'm really glad I wrote that wiki page, I had completely forgotten about those ideas. It seems to me that what we want to do at starting is like a GC: we traverse all the static objects copying them to a new area and updating all the internal pointers at the same time. You can arrange that all the indirections end up next to each other by putting them in a special section. Then you can traverse the contents of the section so long as you have a symbol at the beginning and the end, or something like that. There are other ways to do it, such as having the module initialisation code register something with the RTS. It pains me to have to use this solution when what we really ought to do is memory-mapping tricks to put the static objects where we want them. Cheers, Simon
participants (1)
-
Simon Marlow