[MLton-devel] mremap() in MLton

[Stephen Weeks]

> Theres caveats to committing totally to do code. First I am an
> undergrad with a tight schedule. Second I know nothing about GC except
> the basics (generations, arenas and a tiny tiny bit about region based
> GC).

Don't worry -- no real commitment here, although we'd certainly be
happy to have you look into it.  These madvise experiments are nowhere
on our critical path.  But they could be helpful, who knows?

> Is it possible to profile the C code of the project (gprof, gcov,
> etc),

I assume so, but haven't done it.  It would be interesting.  When we
use "mlprof -s" we do get to see the time spent in each C function (gc
included).

> or should I put counters in each function and do it that way? Before
> that, there is no reason the mangle the heap of the GC. We need to be
> pretty sure that it is the lack of mremap() that affects the speed
> difference. If not then, by murphys law, we are going to introduce more
> errors.

My own approach to deciding if madvise is helpful is that it is simple
enough to add the madvise calls and run the benchmarks with and
without the calls.  No profiling required.

As to mremap, I agree some profiling might help there.

> Ive been down over the garbage collector code (yesterday). I wondered
> where mremap() was used. But I have not done any in depth reading. 

The only call to mremap in gc.c is in heapRemap, which is used in
growHeap.  Note that on Cygwin and FreeBSD heapRemap is a no-op.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel