Thanks Jeff! I've re-applied c74900ca6724 with a modified version of these fixes in 7dcd0042e8b.

Oops -- I missed that. Thanks for reverting! I'll recommit with a fix
shortly.

Fix broken diff (hopefully).

Add a unit test.

Looks like Sourabh already got this in db464a2753e2b3dee7a1438cd8ccc33795fc9529. Thanks to both of you. :)

LGTM. Thanks for catching that!

@lhames yes, we plan to deprecate it in the future.
For now, by using backwards compatibility, we allow users to switch to the old flow in case of problems with the new one.

I'm not familiar with the profiling listeners. Out of interest: Is the backwards compatibility mode necessary? Is there a plan to deprecate it in the future?

In D85974#2229168, @sgraenitz wrote:

Back to the review: I'd like to keep the test for the example and see how the build servers behave. Generally it might be useful to have tests for all the "LLJITWith..." examples right?

In D85974#2229156, @sgraenitz wrote:

I will get back to performance evaluation maybe in a few weeks and sure I am happy to share my progress.

If query handlers were dispatched rather than running on the thread that satisfies the last query dependence it should expose some new opportunities for concurrency.

Indeed, that sounds promising. I hope it doesn't require adding more locking to the engine? In general, performance analysis only works in combination with comprehensive benchmark data. Maybe a good opportunity to create a benchmark suite for tracking both, single- and multi-threaded performance over time?

In D85974#2218483, @sgraenitz wrote:

In D85974#2218405, @lhames wrote:

What performance issues did you run in to with threading and performance? I haven't had a chance to look in to that yet.

Performance gains inherently depended on a smart handling of fine-grained async tasks. Otherwise the runtime cost for handling concurrency is easily eating up the gains quickly. I have the impression that the LLVM ThreadPool implementation is too limited here, e.g. there is no mechanism for priority-based scheduling. Trying to walk around the limitations added at lot of complexity that I didn't manage to handle. It might be easier with a decent threading library at hand or maybe a Rust-like async/await. More experiments to come out-of-tree :)

What performance issues did you run in to with threading and performance? I haven't had a chance to look in to that yet.

Sorry I missed this one earlier. Looks good to me too.

In D85919#2216614, @sgraenitz wrote:

I didn't see a memory manager in the new TargetProcessControl API (yet). Maybe it can also be migrated there.

What's all the clang-tidy errors from pre-merge check? Haven't had any linting issues locally. Are we supposed to add entries to this clang-tidy.ignore?

This is amazing timing too -- I'm actually working on ORCRPCTargetProcessControl implementation right now, but haven't had time to write an allocator for it yet. Would you mind if I moved yours into a header once my patch is ready?

Oh yeah -- that's way better. Thanks!

LGTM. Thanks Stefan!

@digit -- Do you have commit access to land this, or would you like me to commit on your behalf?

Sorry for the delay! LGTM.

I don't see any reason for RODataMem to be mapped executable. I don't think this will break anything, but if it does the fix would be to update RuntimeDyld to ensure any code that needs executing ends up in CodeMem.

LGTM -- Thanks very much Jared!