[llvm-dev] [ORC] Removing / replacing JITDylibs

[Andres Freund via llvm-dev]

Hi,

On 2019-08-22 14:23:48 -0700, Lang Hames via llvm-dev wrote:
> Unfortunately we don't have a good way to do this at the moment, short of
> maintaining multiple execution sessions (analogous to the way you
> maintained multiple ExecutionEngines).

FWIW, I/we use Orc v1, via the C stack, for compiling parts of SQL
queries. We currently rely quite heavily on being able to deallocate
"modules". I asume it'd be a problem for us to migrate to v2 due to that
right now (ignoring the fact that there's no C API right now ...).

I have not yet benchmarked it, but it looks like it'd be fairly
noticable to create a separate ExecutionSession for every set of
functions I'd want to be able to deallocate inidividually.  And it's not
straightforward to just use ExecutionSessions in a "generational"
manner, as the lifetime of JITed expressions can vary widely (from
seconds to many days in the case of a longrunning query, which might
spawn many shorter queries internally).


Is that prototype available somewhere?


I'd be interested in replacing the current C stack with LLJIT (wrapping
it in C again, potentially even with a roughly compatible interface),
but especially if one desired to take advantage of the nicer features,
say parallel compilation, it looks infeasible to just create separate
LLJIT instances over and over.


> I am working on initializer/destructor support that will allow us to
> perform the equivalent of dlopen/dlclose on JITDylibs. Once that support is
> available I think it would be a good fit for your use case. Unfortunately I
> think it is still a few months away.

On 2019-09-02 12:26:48 -0700, Lang Hames via llvm-dev wrote:
> Actually, if my current prototype pans out then there might be an even
> better solution for your use case: I'm hoping to provide fine-grained
> removal of modules from within a JITDylib (without removing the whole
> JITDylib). The advantage of this is that it's easier to reason about
> (functions can go in the conceptually "correct" JITDylib, even if you want
> to remove them later) and less expensive (It's more expensive to maintain
> one JITDylib per function than to maintain one JITDylib with many
> functions).

Interesting.  Are you thinking of providing both, wholesale JITDylib and
excision of individual functions? In postgres' case the modules we add
contain a bunch of exposed function, and then (depending on the cost of
the query) a lot of C functions and required globals (copied in the case
of static constant ones) that have been "inlined" from the main binary,
to allow for proper IPO.  It seems like it might be hard to support that
case efficiently without replacing JITDylibs wholesale?


The new APIs look much cleaner to me. Thanks for all your work on that!


Greetings,

Andres Freund