[erlang-questions] Automated Stripping of otp libraries / modules

[Thomas Lindgren]

>________________________________
>From: Matthias Lang <matthias@REDACTED>
>To: Dale Harvey <dale@REDACTED>
>Cc: erlang-questions <erlang-questions@REDACTED>
>Sent: Thursday, June 23, 2011 4:49 PM
>Subject: Re: [erlang-questions] Automated Stripping of otp libraries / modules
>
>Hi,
>
>Dale Harvey asked about how to figure out what modules are actually
>needed in a system. I promised to try out some different approaches on
>the control system for the hardware I work on.
>
>Executive summary:
>
>   - Using my code:all_loaded() approach nets me 153 modules
>   - Xref looks like a dead end. Xref gives me 475 modules in a simple analysis
>   - Dialyzer might be able to do better. I don't know.


Regarding static analysis, I seem to recall that Sven-Olof Nyström's soft typing analysis iterated control flow and dataflow analysis, and could thus (at least in theory) figure out the higher-order calls and get a tighter bound than xref.

Here is the page: http://user.it.uu.se/~svenolof/SA/
You will have to talk to Sven-Olof if there are any support issues.

Unfortunately, the control flow analysis problem is difficult, so we can't expect too much in the general case. Just adding closures to the language makes control flow tricky. In erlang, we furthermore have some extra complications, e.g., constructing module and function names at runtime and invoking them.

As you note later on, modules furthermore sometimes group unrelated functions and so the module call graph can yield irritating false dependences. Some years ago, I saw exactly this problem when developing a high-level optimizer for erlang; it can get particularly annoying with libraries like lists. My solution then was to start off with a round of (automated) module splitting. That might not be for everyone, of course.

Best,

Thomas