Erlang Micro Edition.
Thu Jun 30 13:49:30 CEST 2005
--- Alex Arnon <alex.arnon@REDACTED> 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
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
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
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.
Stay connected, organized, and protected. Take the tour:
More information about the erlang-questions