Getting rid of HEAP_ALLOCED

[Simon Marlow]

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