HiPE to be removed in OTP 24?

[Mikael Pettersson]

On Sat, Jun 20, 2020 at 10:05 PM Grzegorz Junka <list1@REDACTED> wrote:
>
> OK, there is a bunch of limitations listed in http://erlang.org/doc/man/HiPE_app.html#feature-limitations
>
> Erlang tracing is one of them. Are those limitations inherent to the HiPE compiler, i.e. they can't be fixed,
> or they are simply there because they haven't been implemented? Or in other words, is AOT compilation
> of Erlang code into native code doomed and JIT is the only solution to speed it up?

AOT compilation of Erlang is not inherently difficult.  The problems
faced by HiPE are due to a few
unfortunate facts:

1. Active development of HiPE ended over 10 years ago.  The people
involved were part of an academic
    research group, but it's been dissolved and the people have moved
on long ago.
2. Although HiPE was made part of Erlang/OTP, the OTP team doesn't
have capacity to do proper
    development of HiPE, limiting them to occasional fixes.  That
means HiPE is falling behind when OTP
    adds new features or changes the VM internals.  Worse, the
presence of HiPE sometimes also
    restricts the OTP team in what they can do.
3. At a technical level, HiPE starts by consuming the BEAM object code
produced by the Erlang compiler
    (I assume other languages targeting the BEAM ought to work too).
Unfortunately that BEAM code
    is constantly changing, both in its instruction set and in what
kind of assumptions the BEAM compiler
    makes (the semantics is somewhat loosely defined).  This is the
reason why binary matching no
    longer works with HiPE.  I don't know why try/catch no longer
works (of course it used to).
    The NIF / on_call limitations are presumably just because no-one
did the needed development work.
4. Tracing is not inherently impossible, but it was never implemented
for HiPE.  You'd just need to
     tell HiPE which native MFAs are being traced so native calls to
them can trap.
5. HiPE's runtime support structures in the VM are messy for
historical reasons, making management
    of code (tracking what's in BEAM, what's in native, what's been
hot-code upgraded) difficult.  That
    part has never been 100% on par with BEAM.

A way to resurrect HiPE could be to:

A. Retarget the compiler to consume a higher-level more stable
intermediate representation from the
    BEAM compiler, perhaps Core Erlang but even that is a moving target.
B. Drop all remnants of being able to native-compile individual MFAs,
just handle whole modules.
     (That restriction is already in place, but the internals still
operate on individual MFAs.)
C. Fix the bugs, streamline the VM interfaces between BEAM and HiPE.

Realistically this would require 6 person-months or more.