[MLton-devel] mremap() in MLton

[Stephen Weeks]

> That implies one big heap. It will get very big indeed. Any
> reason for not splitting it into smaller parts?

The real reason is historical -- that's the way it's always been, for
simplicity's sake.  It hasn't changed because I've never been
convinced it would lead to performance improvement and I've been
worried about address space fragmentation.

> Anyway it requires rewriting the GC. And we all know that is a hard
> and touchy point.

Indeed.  If I had to guess, it's a few weeks of work to split the heap
up.  I wouldn't object to someone doing the experiment, but it's not
even on my radar.

> Have it been discussed how to utilize the cache correctly (when copying
> generations, storing them in the cache purges the program, resulting in
> a lot of misses afterwards...)? Using a call as madvise() would hint at
> least the VM of the state of the memory.

I'll keep that in mind.


-------------------------------------------------------
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