On 26/07/16 14:58, Neeraj Sharma wrote:
As anticipated Erlang
VM is requesting for larger chunk 1GB of memory while VM is running
256MB which surprisingly goes into an infinite loop within rumprun.
I have raised an issue https://github.com/rumpkernel/rumprun/issues/81
to track the same and will be great if it's looked at.
ic. Well, that doesn't really seem too hard to fix, especially on the
Erlang VM side. It's a classic case of "we're running on top of virtual
memory, so let's just allocate silly amounts".
I agree that application should be updated (at some point) to
understand the operating system it is running although rumprun does
make initial porting effort much easier. Having said that I believe it
will be easier (for debugging) to just fail the allocation instead of
just spinning infinitely from an end-use point of view. This will be
of great help to dev like me who did not write either software and
trying to make them work together :)
Again, like I mentioned below, the rump_hypermalloc() interface is not
really meant to be used directly by applications. It's an accident
(a.k.a. bug) that it is.
Since callers of rump_hypermalloc() aren't stupid (they're kernel code), I'd
say that the right fix is to call hypermalloc with waitok = false and put
some sort of uvm_wait() logic into mmapmem_alloc().
Is there a cleaner/better way to remove mmap support in rumprun, so
applications wont find it and am curious to see how that goes with my
case (for the fun of it though).
Beyond commenting the offending source module out of the rumprun_base
makefile, not that I know of. Should there be? I'm not against it, but
before we design a grand and ubergeneral abstraction, just comment it
out of the Makefile and see where that gets you.
