Erlang Micro Edition.

[Thomas Lindgren]

--- Alex Arnon <alex.arnon@REDACTED> wrote:
> I'd like to envision an Erlang VM which would
> perform all (or most)
> high-level services:
> - It would have access to sockets (including RAW
> ones) and pipes.
> - It would be able to open files and read/write.
> binary<=>eterm would
> be useful in any case.
> - I would like to be able to easily build and link
> in port drivers for
> controlling special devices.
> - I would like to be able to constrain resource
> usage per application, e.g.:
>     - Process priorities.
>     - Memory usage constraints (per-process or
> process group).

At present, there is no support for memory constraints
inside of Erlang. Also, there is no raw socket
support. (Though there seems to be a libpcap driver
somewhere out there.)

> Now, how cut-down would the functionality of such a
> VM and standard library be?

Mildly extended, considering the above; though you
could in principle get rid of some stuff too.

> Would a statically-linked one take less than a MB?
> More? About 500KB, maybe? 

Difficult to say, though Matt Lang's experience in
that other mail indicates <5MB in toto for something
reasonable. 

>From the process statistics, it looked like the
current emulator was about 1.4 MB + data areas. You
could pare it down in three ways (at least). All of
them will need a bit of non-standard digging in the
code.

1. Get rid of unused Erlang code -- edit stdlib.app
and kernel.app and pray.

2. Get rid of unused BIFs -- edit or remove the C
files and edit the appropriate config tables so that
those primitives are not provided to the compiler.
Pray some more :-)

3. Pulling out deeply integrated functionality. Well,
hack it until it works, I guess.

I'd do them in that order, as needed, basically.

> How about the runtime usage? Could we write a DHCP
> server that would
> need only 30KB of heap space? A web management
> interface - 200K?

A fresh erlang process is normally pretty small --
about 1 KB of "overhead". The process stack is shrunk
and grown automatically as needed. Here is some more
data:

http://erlang.se/doc/doc-5.4/doc/efficiency_guide/advanced.html

A simple protocol FSM doesn't need a lot of data on
top of that. For DHCP, I guess you will also use
timer.erl to keep track of leases and an ets table for
keeping track of assigned addresses. It doesn't sound
too demanding, spacewise.

Considering web servers, there are a couple already
(inets, yaws). Those are fairly full-featured, but
serving a static page, say, still shouldn't be too
costly. I'm not sure about the current space costs,
but my intuition is that they are modest.

There are three costs to consider:
- the extra erlang code for a feature
- the persistent space (e.g., ets tables and server
processes) to provide the service
- the transient space (e.g., the allocation done to
service a single request)

Hmmm ... In the end I guess there is no substitute for
a bit of experimentation :-)

Best,
Thomas



		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com