[erlang-questions] Why can't HiPE inline functions across modules?

[Thomas Lindgren]

--- On Wed, 11/19/08, Tony Arcieri <tony@REDACTED> wrote:

> From: Tony Arcieri <tony@REDACTED>
> Subject: [erlang-questions] Why can't HiPE inline functions across modules?
> To: "Erlang Questions" <erlang-questions@REDACTED>
> Date: Wednesday, November 19, 2008, 12:41 AM
> I've read that HiPE can't inline functions across
> modules.  Is this merely
> an implementation issue of HiPE, or is there some
> intractable problem I'm
> missing?
> 
> People typically bring up code change as the reason,
> however I don't see why
> HiPE couldn't walk the graph of modules for which
> inlining has been
> performed during a code change and deoptimize them all back
> to their
> original state, then start all inlining for these modules
> over from scratch
> again.
> 
> Is there an intracticble problem I'm missing, or is
> cross-module inlining a
> feature that should appear on a HiPE wishlist?

Aha, a favorite old topic of mine. Here are some pointers to a more "compiler-based" approach that shows some of the issues and a bit of the potential, at least:

Thomas Lindgren. Module Merging: aggressive optimization and code replacement in highly available systems. Uppsala University TR 154, 1998.
(ftp://ftp.csd.uu.se/pub/papers/reports/0154.ps.gz)

Thomas Lindgren, Cross-Module Optimization of Erlang. EUC 2001.
(http://www.erlang.se/euc/01/thomasl.ps)

Thomas Lindgren. Profile-driven Inlining for Erlang. EUC 2003.
(http://www.erlang.se/euc/03/proceedings/1630Thomas.ps)

The deoptimization approach has, as I understand it, been taken far in Java after being proposed for Self. Unfortunately for a low-budget community, it looks like a great deal of unglamorous, grotty engineering and testing to get it working flawlessly :-) 

Let's say someone wants to do it anyway. For Erlang, a start might be to implement and expose suitable low-level linking and loading primitives in Hipe and work from there. (Hipe already does dynamic linking, so it could be straightforward to repurpose and extend those.)

Best,
Thomas