Re: Anonymous mmap in the runtime unsupported in openmvs environment

Hi Matthew,

I've made some modification to mlton according to your suggestion and it
works on open mvs. That's great! Thank you.

I tested a few small programs, such as print out a message, work perfectly.
But unfortunately there is a problem with mlyacc. I compile it with
'-target s390-ibm-openmvs -codegen c -stop g' to generate c source code and
then uploaded them. The c source code compiles but the binary raises an
exception "Subscript" during execution (simply run ./mlyacc with no
arguments).  I guess it is raised somewhere accessing the list structure,
and I need to make some further investigation into it.


2013/4/19 吴佳森 <[email protected]>

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

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr

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