Changing Code

[Sean Hinde]

Hi,

Some feedback from our systems used in an in house development model with
separate support teams who manage the live systems.

> 	- 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?)

We use the ability to change a single module pretty regularly. We tend to
put stuff which is kinda config but not really into a single module and
issue a new version when something changes. We also update general library
modules quite often.

> 
> 	- 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.)

I would never like to have to predict where something is likely to change.
Neither bugs nor Marketing are friendly to such predictions!

> 
> 	- 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?

When we are just changing a few library modules we load them with
code:load/1, otherwise we tend to have the node restarted - unless it is a
big mnesia database where we can just do an application:stop/1 on the
offending application, code:load/1 and then application:start/1.

We do not use the .appup etc stuff from OTP at all - mainly because it is
just a little too scary (from the point of view that you don't quite know
what it is up to).

> 
> 	- How much of a problem are circular module dependencies in
> 	  practice?

We've not hit this one yet

> 	- 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?

Yes, I'd say do for us. Code change at that level is one of the killer
feaures which makes Erlang so astonishing..

We are not currently CPU limited for any of our apps. The only times for us
where profiling tends to throw out problems are when there is simply a lot
of data to chug through 1 octet at a time - but these types of code tend to
not call external modules that often, and will probably respond well to
straight HIPE compiling (or a driver, or a fixed algorithm).

How much speedup do you think would be achievable?

> 	- 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.

I really like the fact that Erlang doesn't have many gotchas. This sounds
like it would very rarely happen but could be a right pain if it did.

> 	- Anything else that you find important.

64 bit erlang :). Seriously, memory per node is our bottleneck at the
moment, not CPU

Regards,

Sean



NOTICE AND DISCLAIMER:
This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.