Erlang Micro Edition.

Alex Arnon <>
Thu Jun 30 20:06:46 CEST 2005


On 6/30/05, Thomas Lindgren <> wrote:
> 
> 
> --- Alex Arnon <> wrote:
> 
> > Christophe, I was thinking more along the lines of
> > trying to assess
> > how large/heavy a ground-up rebuild of a VM that
> > will be as simple as
> > possible, with a minimum of BIFs and features.
> 
> First of all, what's the point of an Erlang without
> BIFs and features?
> 
> OK, I'm being a bit facetious, but there has to be a
> reason to choose Erlang too. Also, I would suspect
> that most developers want to add more nifty stuff for
> the next model, so things will likely creep back in.
> 
> Restructuring the system to get rid of unused features
> may be a Good Thing even so. (By moving more features
> into Erlang, one can omit them more easily.)
> 
> > My gut feeling tells me that a ground-up rewrite is
> > necessary:
> 
> Uh-oh :-) First, let's see what can be done to the
> existing system. As a simple baseline, I stripped an
> R9C2 installation (x86, slackware):
> 
> (I'm not sure how the executables are used, so I list
> them all)
> 
> Before strip:
>  4282779 beam
>  4306296 beam.elib
>  4305231 beam.elib.shared
>  4281706 beam.shared
> 
> After strip:
>   970192 beam
>   978544 beam.elib
>   985008 beam.elib.shared
>   976656 beam.shared
> 
> So there are some easy gains to be made in storage
> space, at least.
> 
> At startup, both the stripped and unstripped beam
> processes appear to occupy about ~4.2 MB of memory, of
> which ~1.4 MB is shared. Some flag tweaking may reduce
> that a bit further.
> 
> The VM sees 2.8 MB of this: 0.6 MB is used by
> processes, and 2.2 MB shared (1.4 MB bytecode from 70
> modules, the rest atoms, binaries, and ets).
> 
> Of course, practical use will size up those areas. One
> real system, when idling after test, has a 7.4 MB VM,
> wherein 1.9 MB is used by processes, bytecode uses 4.0
> MB (~250 loaded modules) and the rest is for ets,
> atoms and binaries. The entire (unstripped) process is
> 13 MB, which I'd say is fairly normal for a realistic
> Erlang node.
> 
> Peak memory use may be much higher, of course. First,
> a database may increase the ets size quite a bit.
> Second, an active system will use more (transient)
> space for processes.
> 
> Best,
> Thomas
> 
> 
> 
> 
> __________________________________
> Yahoo! Mail
> Stay connected, organized, and protected. Take the tour:
> http://tour.mail.yahoo.com/mailtour.html
> 
> 


Thomas,

I'd like to give an example of what I would use a Micro-Edition for:

Small device, e.g. home ADSL router. This machine would have a small
Linux or NetBSD kernel running, possibly an SSH daemon and a few other
processes. Memory budget = ~8MB. Maybe 12 or 16.
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).

Now, how cut-down would the functionality of such a VM and standard library be? 
Would a statically-linked one take less than a MB? More? About 500KB, maybe? 
How about the runtime usage? Could we write a DHCP server that would
need only 30KB of heap space? A web management interface - 200K?



More information about the erlang-questions mailing list