[MLton-devel] mremap() in MLton

[jlouis@diku.dk]

On Thu, Sep 19, 2002 at 09:45:08PM -0700, Stephen Weeks wrote:
> Jesper, if you're interested in doing some coding to help us out, it
> would be a reasonably simple and self-contained experiment to see if
> you could get consistent performance improvements (on FreeBSD or
> Linux) with suitable use of madvise.  If you haven't seen it yet, the
> place to look is doGC() in runtime/gc.c.

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

That said, I tend to study best by having a target and researching that
particular target. It doesnt get you through courses, but it certainly
makes it fun. Garbage Collectors could be a fine area this fall. I will
have to read some papers on GC at least to have some ideas of what
people have done in the area.

Is it possible to profile the C code of the project (gprof, gcov, etc),
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.

If I were to write a better garbage collector for FreeBSD/Linux I think
we should get rid of that enormous allocation. however, I have no papers to
back me up (yet).

I just throw some ideas on the table and try to see how they are being
taken. Another one is to lure the C compiler into prefetching large
chunks into the cache. This could be especially handy when copying
sequential data (which it seems moving from the old to the new generation
does). The caveat, however, is that this binds us to a traditional
cached environment. It isnt pure in the sense of C.

Ive been down over the garbage collector code (yesterday). I wondered
where mremap() was used. But I have not done any in depth reading. My
further study of the mremap() led me to the linux compatibility calls in
FreeBSD. linux_mremap() in /usr/src/sys/compat/linux (FreeBSD tree [1]).
Not much to gain there though, since they just return a ENOMEM when
trying to grow memory. And munmap()'s the region if its a shrink.

[1] For the curious:
  http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/linux_misc.c?rev=1.129&content-type=text/x-cvsweb-markup

-- 
Jesper
 EMACS == Escape Meta Alt Control Shift???


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