Load CppInterOp explicitly instead of from a global constructor

[aaronj0]

The backend used to dlopen libclangCppInterOp from a global constructor, which runs inside the dlopen of libcppjit itself when Python loads the extension. The nested dlopen re-enters the loader on partially consistent state, runs the inner library's initializers with no ordering guarantees, and holds the loader lock through the entire interpreter and JIT setup, deadlocking any other thread that touches the loader (as reported by @Vipul-Cariappa). The constructor also had no error channel: on failure it printed and left a half-initialized library.

CppInterOp loading and interpreter setup now run in an exported, idempotent LoadCppInterOp() that _cpython_cppjit.py calls before the extension module import. This returns a status that turns into a proper exception on the Python side. The ApplicationStarter global is dropped in favor of a clean set of statics, all called by LoadCppInterOp().

[github-actions]

Test Results

Configuration	Result
macos-26-intel-llvm21-py3.14-cxx20	= 437 passed, 44 skipped, 85 xfailed, 32 xpassed, 100 warnings in 144.72s (0:02:24) =
macos-26-llvm21-py3.14-cxx20	==== 438 passed, 37 skipped, 93 xfailed, 30 xpassed, 100 warnings in 53.42s ====
ubuntu-24.04-llvm21-py3.14-cxx20-vg	====== 553 passed, 25 skipped, 18 xfailed, 2 xpassed in 94.57s (0:01:34) =======
ubuntu-24.04-llvm22-py3.14-cxx20	====== 553 passed, 25 skipped, 19 xfailed, 1 xpassed in 110.75s (0:01:50) ======
ubuntu-24.04-llvm22-py3.14-cxx20-cling	====== 543 passed, 25 skipped, 27 xfailed, 3 xpassed in 101.92s (0:01:41) ======
ubuntu-24.04-llvm22-py3.14-cxx23	====== 574 passed, 3 skipped, 20 xfailed, 1 xpassed in 105.70s (0:01:45) =======

[vgvassilev]

That in practice slows things down because most of the functions are not in hot loops.

[aaronj0]

That means it is already slow, because this is not a change that I introduced in this PR, it always has been like this in the forks (and cppyy upstream). My changes are non functional w.r.t what we actually do at interpreter setup time.

What would be the right optlevel?

[vgvassilev]

0 is the right default and #pragma XXX optimize N should be the annotation for hot code. If that's not new we can measure before and after changing but ROOT had 50% slowdowns when switching from 0 to 1 iirc.

[aaronj0]

Okay but currently we don't have a way of #pragma XXX optimize N for clang-repl. Ideally we should guard the following:

  if (optLevel != 0) {
    std::ostringstream s;
    s << "#pragma cling optimize " << optLevel;
    Cpp::Process(s.str().c_str());
  }

with CPPJIT_USE_CLING since it does not do anything in the clang-repl case.

And in the case of ROOT none of this would apply because the interpreter is created by ROOT, and none of this code runs.

[aaronj0]

0 is the right default and #pragma XXX optimize N should be the annotation for hot code. If that's not new we can measure before and after changing but ROOT had 50% slowdowns when switching from 0 to 1 iirc.

And yes, that is not new. You can see in the diff.

[vgvassilev]

I think we should set the opt level to 0 and move on for now.

[aaronj0]

Will address in a follow up patch. I realise we should not unconditionally do Cpp::Process("#pragma cling optimize " << optLevel;")) because that only runs in the clang-repl case, so that would be an unrelated change to what this patch does.

[aaronj0]

And we can update that once llvm/llvm-project#214793 lands

[vgvassilev]

Will address in a follow up patch. I realise we should not unconditionally do Cpp::Process("#pragma cling optimize " << optLevel;")) because that only runs in the clang-repl case, so that would be an unrelated change to what this patch does.

The equivalent of that code would be to pass the -O2 flags to the interpreter. No pragma is needed because it is done on global scope probably intends to make a TU-wide setting.

[aaronj0]

Okay makes sense. So we pass -02 by default when creating the interpreter

[aaronj0]

@vgvassilev Addressed your request to separate the fix from the NFC refactor. I would prefer to keep them in the same PR though, having just the refactor into smaller static functions does not seem worth bloating the history.

Commit 1: Replace _applicationStarter with a thread-safe static LoadCppInterOp invoked from Python at setup, that sovles the nested dlopen
Commit 2: NFC: Refactor the body into subfunctions that improve readability and localise each substep of setting up the interpreter

[vgvassilev]

Thank you, @aaronj0. LGTM!