> 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.
On 27 Aug 2013 19:59, "Edward Z. Yang" <ezyang at cs.stanford.edu> wrote:
> Excerpts from Simon Marlow's message of Sun Aug 25 12:56:06 -0700 2013:
> > 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.
> If I understand correctly, this is not true if you do something like
> dynamic linking, in which case each dynamic library will have its
> own indirection region. So in that case, every library should register
> its boundary symbols with the RTS.
Yes, sorry I forgot to mention that.
Alternatively having each module register its table might be easier.