Re: Anonymous mmap in the runtime unsupported in openmvs environment
吴佳森 <[email protected]> Fri, 19 Apr 2013 16:20:02 +0800
| Newsgroups | gmane.comp.lang.ml.mlton.devel |
|---|---|
| Message-ID | <CAKCzkEqZwop_4znyejs0Hxumg3AKd5W9Uq0=dCQecsbjQZWtXQ@mail.gmail.com> |
Thank you, Matthew. malloc() does not rely on mmap() on openmvs environemnt. I'll have a try and see the impact. 2013/4/18 Matthew Fluet <[email protected]> > 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 > > ------------------------------------------------------------------------------ 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