Mon Aug 12 13:31:16 CEST 2002
The dynamic code update semantics of Erlang is a nice feature when
you're in prototyping mode, but for production code, the fact that any
inter-module ("remote") call can be redirected at any time to a new
version of the called module is a big obstacle for the compiler when it
comes to generating efficient code. To be able to maybe do something
about this, we'd like to know more about how code update is actually
being used (and handled) in real Erlang systems of today. Things we
would like to hear about include:
- Is it necessary to be able to exchange any single module?
(E.g., if your application consists of a number of modules,
do you always replace all these modules anyway?)
- Could code migration be limited to specific functions, or
is it necessary to be able to switch to a new version at all
"remote" calls. (E.g., one could imagine a new declaration
for specifying only certain functions as code update points.)
- Do you always use the OTP release handler or similar to
do code updates, or do you do it by hand, or with your own
in-house tools, etc? Do you find it simple as it is today,
or is code update so difficult that you try to avoid it?
- How much of a problem are circular module dependencies in
- Is the flexibility of being able to change any module at any
time (even in production code) worth more to you than the
speed of the code?
- When you make a (remote) call that is expected to switch
to new code whenever it has been loaded, could you guarantee
that the call stack is empty at that point, i.e., you will
not return to the old code, nor to the code that called it?
(If so, the code purging stage would not have to scan the
stacks of processes to find out if they must be killed.)
This pretty much equals saying that code change always starts
a fresh process, but keeps the old Pid.
- Anything else that you find important.
/Richard & the HiPE posse
Richard Carlsson () (This space intentionally left blank.)
E-mail: WWW: http://www.csd.uu.se/~richardc/
"Having users is like optimization: the wise course is to delay it."
-- Paul Graham
More information about the erlang-questions