[llvm-dev] ORC JIT Weekly #1

[Andres Freund via llvm-dev]

Hi Lang,

On 2020-01-28 13:35:07 -0800, Lang Hames wrote:
> I also want to highlight the necessity of some form of C API, that others
> > already have.
> >
> <snip>
> 
> > It's fine if the set of "somewhat stable" C APIs doesn't provide all the
> > possible features, though.

> Ok. This got me thinking about what a simple LLJIT API should look like. I
> have posted a sketch of a possible API on http://llvm.org/PR31103 .

I'll take a look.


> I don't have time to implement it just yet, but I would be very happy
> to provide support and review patches if anyone else wants to give it
> a shot.

Hm. I don't immediately have time myself, but it's possible that I can
get some help. Otherwise I'll try to look into it once my current set of
tasks is done, if you haven't gotten to it by then.


> > What's the capability level of ORCv2 on RuntimeDyld compared to ORCv1?
> > Are there features supported in v1 that are only available on JITLink
> > supported platforms?

> At a high level, ORCv2's design allows for basically the same features as
> ORCv1, plus concurrent compilation.

Cool.


> There are still a number of APIs that
> haven't been hooked up or implemented though. Most prominently: Event
> listeners and removable code. If you're using either of those features
> please let me know: I do want to make sure we continue to support them (or
> provide an equivalent).

Heh, I/pg uses both :(

WRT Event listeners: I don't quite know how one can really develop JITed
code without wiring up profiler and debugger. I'm not wedded to the
event listener interface itself, but debugger & profiler are really
critical. Or is there a different plan for those features?

WRT removable code:

Postgres emits the code for all function it knows to need for a query at
once (often that's all that are needed for one query, but not always),
and removes it once there are no references to that set of functions
anymore. As one session can use a *lot* of code over its lifetime, it's
not at all feasible to not unload.  Right now we use
LLVMOrcRemoveModule(), which seems to work well enough.  FWIW, for that
usecase there's never any references into the code that needs to be
removed (it only exports functions that need to be called by C code).

It doesn't look all that cheap to just create one LLJIT instance for
each set of code that needs to be removable. I don't really forsee using
LLVM side lazy/incremental JITing - so far my experiments showing that
the overhead of a code generation step makes it unattractive to incur
that multiple times, and we have an interpreter that we can use until
JIT compilation succeeds. So perhaps it's not *that* bad?

What is the biggest difficulty in making code removable?


In case you happen to be somewhere around the LLVM devroom at fosdem I'd
be happy to briefly chat in person...

Greetings,

Andres Freund