In my very limited understanding of JIT, it utilizes two kinds of memory allocations. There is SLJIT_MALLOC with a corresponding SLJIT_FREE, and I think those could be (or should be) within the scope of this discussion.
But there is also utilization of executable memory that enables its operation in DEP (Data Execution Prevention) environments. There is SLJIT_MALLOC_EXEC / SLJIT_EXECUTABLE_ALLOCATOR, and its Windows implementation deploys VirtualAlloc() requesting PAGE_EXECUTE_READWRITE. In this case JIT has a specific memory requirement. Exposing that to general application programs may not be desirable. Doing so may lower the probability of successful implementations. That portion of memory management should probably remain internalized to the JIT implementation and not made accessible. Also it should be mentioned that global read/write variables exist in JIT. For example sljitLir.c contains: static int compiler_initialized = 0; And sljitExecAllocator.c contains: static struct free_block* free_blocks; static sljit_uw allocated_size; static sljit_uw total_size; There are others such as a couple of important mutexes. These globals seem to be used in ways that do not detract from your overall goal. In reviewing limited portions of the code, I don't think there would be conflict with multiple disparate threads using a single shared library instance. In sljitLir.c line# 272 it seems possible that a timing sequence would allow more than 1 thread to invoke init_compiler(), but to me that doesn't appear critical. If it is then that portion could be wrapped with something like sljit_grab_lock() and sljit_release_lock(). Regards, Graycode -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
