Re: [pcre-dev] [Bug 1174] allow passing of pcre_{malloc, fre…

Top Page
Delete this message
Author: Graycode
Date:  
To: pcre-dev
Subject: Re: [pcre-dev] [Bug 1174] allow passing of pcre_{malloc, free, stack_malloc, stack_free, callout} as parameters
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