Re: Anonymous mmap in the runtime unsupported in openmvs environment

Matthew Fluet <[email protected]> Thu, 18 Apr 2013 09:20:57 -0400
Newsgroups gmane.comp.lang.ml.mlton.devel
Message-ID <CAMrhFL4ps72tH5DsEwxM2_3=L9OysP=WHSs5D9oLkVLA__Ws7w@mail.gmail.com>
On Thu, Apr 18, 2013 at 1:28 AM, 吴佳森 <[email protected]> wrote:

> Hi. I'm doing some experiments on mlton runtime. I am trying to port it
> S390 openmvs environment. Openmvs is a minimum unix-like environment.
> Almost everything goes well, but the platform-dependent parts fail. The
> GC_mmapAnon() cannot be implement. I looked up the mmap in C runtime
> library manual on openmvs and found out that the MAP_ANON is not supported.
> I also tried some workarounds such as using MAP_PRIVATE with /dev/zero, but
> it's also not supported.
>
> GC_mmapAnon(), GC_remmap() and GC_munmap() has similar functionality as
> malloc(), realloc() and free(). Can I just implement GC_mmapAnon() with
> malloc(), by ignoring the first parameter (which is a suggested location of
> storage allocation)? Will there be anything particular to consider about?
>
> GC_mmapAnon() seems to be the interface to obtain a piece of memory in
> createHeap(). There is a piece of code with loop to find a location where
> storage request can be satisfied by mmap. But I cannot see the reason that
> mmap() be better than something like a direct malloc. Could someone help me
> on this?
>

In general, yes, you should be able to use malloc for GC_mmapAnon and
realloc for GC_remmap.  However, it won't be quite as easy to use free for
GC_munmap.  We use munmap to both release a heap and to shrink a heap; see
"shrinkHeap" in runtime/gc/heap.c.  You might be able to support the
shrinking behavior with realloc.

Most implementations of malloc fall back to mmap for large allocations, so
it is a little more efficient to directly use mmap.  There are some systems
where there are strong assumptions that malloc will only be used for small
allocations and that malloc will never fail; this is particularly true on
MacOSX, where (by default) stderr messages are generated each time a malloc
fails.  Since (on 32bit platforms) it is not uncommon to request an
allocation that cannot be satisfied and we back off with successively
smaller heaps, the error messages are really noise.

------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter

_______________________________________________
MLton-devel mailing list
[email protected]; [email protected]
https://lists.sourceforge.net/lists/listinfo/mlton-devel