appspace pollution & SERC EC compiler

[Lawrie Brown]

Hi

On Mon, Nov 11, 2002 at 01:00:23PM -0000, Sean Hinde wrote:
> This is a big concern as Erlang creeps ever closer to living on the internet
....
> Also various people have proposed things to lock down erlang distribution:
> * Various works at SERC - mainly about non trusted code execution though
> some nice stuff about secured gen_servers

Just a quick note to say we're still here and plugging away quietly :-)

I've spent the last few months building a decent sized runtime for the
EC compiler that Maurice Castro developed at SERC and its getting closer
to the point where we're happy enough with it to announce its availability
for people to play with. But given the above & other recent comments I
thought I'd dangle a teaser in case there's some interest.

Very briefly - EC is intended to be a native-code compiler for (a decent
sized subset of) Erlang. It is intended both as the core compiler for 
the Magnus massively scaleable computing system, as well as a testbed
for the extensions I proposed for a Safe Erlang.

Currently it recognises most of the language as defined by the Erlang
book & the Erlang Ref 4.4 (ie circa 1999 vintage).  The current backend
is for x86 BSD/Linux systems, though the compiler and the runtime both
build & test on MacOSX & Solaris as well (ie you go figure which
backends are coming next, we hope ;-)

The runtime I've been working on implements an Erlang node as a heavy-weight
address space protected Unix process. Erlang processes are implemented as
detached system scheduled pthreads (ie can take full advantage of multiple
CPU systems). Dynamic module loading is implemented using libdl (ie dlopen()
& friends). Because we are working with compiled code - we can dynamically
load not just Erlang but any compiled modules that conform to the naming/
info conventions we require (the runtime test suite includes loading of
C modules). I'm still working on code update - loading a new version of a
module is easy, and because its inserted ahead of the old in the loaded
modules table, all new apply's etc will use it - the fun bit is tracking
who'se still in the old version - have some ideas on that.

Another key feature is the use of a general capability type with access
rights to replace the current pidportref type. This has been
generalised to manage open files, net connections, (sub)nodes & loaded
modules as well. There is a placeholder for ports, but we don't use
them in EC nodes (file & net are handled separately, and you don't need
drivers as you can call compiled modules directly).

Whats missing? The big ones are the external binary format & hence
distribution.  Coming soon I hope - the intention is for EC nodes to
appear as C-nodes to OTP systems, modulo differences due to different
data representations (esp wrt the capabilities). We also need to
fully implement the hierarchical subnode concept thats part of my 
safe erlang extensions (and complete the garbage collection handling!)

So a bit to do yet! But still, if anyone is interested in having a look or
play, the current (evolving!) CVS tree is available from the EC site 
currently at (nb will move in new year):

    http://www.serc.rmit.edu.au/~ec/

There's also some words etc on my safe erlang research page (full doco 
ALSO is yet to be done) at:

    http://www.unsw.adfa.edu.au/~lpb/research/sserl/

Hope this is of some interest!

Cheers
Lawrie

------------------------------------ <*> ------------------------------------
Post: Dr Lawrie Brown, Computer Science, UNSW@REDACTED, Canberra 2600 Australia
Phone: 02 6268 8816    Fax: 02 6268 8581    Web: http://www.adfa.edu.au/~lpb/ 
nb. currently on sabbatical at SERC, RMIT, Melbourne.