Re: Anonymous mmap in the runtime unsupported in openmvs environment

吴佳森 <[email protected]> Fri, 19 Apr 2013 16:23:19 +0800
Newsgroups gmane.comp.lang.ml.mlton.devel
Message-ID <CAKCzkEqcPBZ_Zhmi_uHVK=dCmXk1U5=7csNh5O4ATMVDfLZEFg@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