Hmm... if we allocate the gc_stack on an aligned boundry, can we recover the arena by keeping a pointer at its base? sort of like I recover the cache block pointer from an arbitrary heap location by rounding down to the block boundry. The main issue would be how it affects allocation speed, its okay to make the GC slower as long as allocation is still fast, Before pre-populating the cache pointers sped things up considerably, how would it make sure to use one from the current arena without slowing down allocation in general? John On Tue, Jun 10, 2014 at 4:42 AM, Kiwamu Okabe <kiwamu@debian.or.jp> wrote:
Hi John,
On Tue, Jun 10, 2014 at 8:28 PM, John Meacham <john@repetae.net> wrote:
Ah. I think I see what you mean by reentrant in your paper. Can you point me to your context switching code in ajhc?
Here is.
https://github.com/ajhc/ajhc/blob/arafura/rts/rts/conc.c#L33
It's a sample with pthread. But CLHs can choose any thread style with calling C code that generate context switch.
Is SMP a concern for you or are you mainly concerned about hardware interrupts?
Both thread on SMP and interrupt. Former uses active context switch, and the example is the above. Later uses passive context switch, however the interrupt context begins on C context. The C context create new "arena" when calling C => Haskell.
Thank's, -- Kiwamu Okabe at METASEPI DESIGN
-- John Meacham - http://notanumber.net/