Can _thread_in_native threads call into Java code? If so, I think you can implement your own lock that’ll do this safely:

• Create three new variables. Using C++0x syntax:
  atomic threads_wanting_to_JIT(0);
  atomic compiler_thread_running(true);
  Object llvm_lock
• The JIT is locked whenever compiler_thread_running=true OR llvm_lock is held. , and by Create a global atomic variable, threads_wanting_to_JIT, initialized to 0. While this is 0, the standard compiler thread gets to run.
• When a thread discovers that it needs to JIT a JNI method, it runs:

    threads_wanting_to_JIT.fetch_add(1);
    synchronized(llvm_lock) {
      while (compiler_thread_running.load()) { llvm_lock.wait(); }
      // Now we know that the compiler thread isn't calling into the JIT (see below),
      // and at most one non-compiler thread can be here because of the llvm_lock.
      CompileStuff();
      threads_wanting_to_JIT.fetch_sub(1);
      llvm_lock.notifyAll();
    }

• Between JIT operations, the compiler thread runs:

    if (threads_wanting_to_JIT.load() > 0) {
      enter_java {
        synchronized(llvm_lock) {
          compiler_thread_running.store(false);
          try {
            llvm_lock.notifyAll();
            while (threads_wanting_to_JIT.load() > 0) { llvm_lock.wait(); }
          } finally {
            compiler_thread_running.store(true);
          }
        }
      }
    }

I’m assuming all sequentially-consistent atomics, or Java volatiles or AtomicIntegers. You may be able to relax the memory ordering some, but it’s probably not worth the risk. Of course, go over the above with a fine-toothed comb before actually using it; it’s easy to make mistakes here.

Notwithstanding the above, using separate LLVMContexts will probably be more efficient overall, unless the JNI interfaces need access to anything from the main compilation Context. With separate LLVMContexts, you won’t have to wait for the main compiler to finish before generating JNI interfaces.