Re: [pcre-dev] option setting for JIT?

Top Page

Reply to this message
Author: ph10
Date:  
To: Zoltán Herczeg
CC: pcre-dev
Subject: Re: [pcre-dev] option setting for JIT?
On Sat, 10 Jan 2015, Zoltán Herczeg wrote:

> well, such option probably suits better to pcre2, since the JIT
> pointer is part of the internal representation of a regex. The
> (*NOJIT) could be an internal flag, which simply prevents JIT
> compilation. The problem with (*JIT) is that we have various
> compilation modes, and compiling in all possible modes would increase
> memory consumption and compilation time (most application use a single
> compilation mode). We could add a dynamic check for pcre2_match, which
> calls the JIT compiler with the appropriate mode (if it is not
> compiled yet) when this flag is set, but it is also an overhead I
> don't really prefer. Philip, what do you think?


Both of these suffer from the same problem when somebody is using a
statically linked application. I do not know if this is a real problem
or just a theoretical one. If from either pcre2_compile() or
pcre2_match() there is a call to pcre2_jit_compile(), even if it is not
activated in a given run, the link will be forced to include the JIT
functions in the static link, thereby making the binary a lot bigger.
Currently, an application that does not call pcre2_jit_compile() can be
linked without including the JIT code.

I don't know if people use static linking much. If they do, I don't know
if they care about the size of the binary. I also don't know if people
build PCRE with JIT and then don't use it. So this may be a non-issue,
but I just don't know.

> Perhaps you could do this in application level, making this as a
> mandatory first option, and simply check the first few characters of
> any regex. If a regex starts with (*JIT)/(*NOJIT) simply skip these
> characters.


I was going to suggest exactly the same solution.

Philip

--
Philip Hazel