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