Project

General

Profile

Actions

Feature #2361

closed

add support for pcre JIT (patch included)

Added by mm almost 10 years ago. Updated over 9 years ago.

Status:
Missing Feedback
Priority:
Normal
Category:
core
Target version:
-
ASK QUESTIONS IN Forums:

Description

With PCRE version 8.20 just-in-time compiling is introduced that significantly speeds up the processing of regular expressions in many cases. As regular expressions are an important part of lighttpd, this speedup might be of high importance.

The attached patch adds simple JIT support to pcre_study() functions in lighttpd and replaces the pcre_free() for pcre_free_study() in relevant places. If JIT does not succeed (incompatible regexp, too small stack) PCRE automatically falls back to old style processing so there should be no problem with this.

The default JIT stack size is 32kb (as in the patch). Should this be not enough for usual lighttpd regular expressions, a customly sized stack may be allocated with pcre_jit_stack_alloc(), assigned with pcre_assign_jit_stack() and freed with pcre_jit_stack_free().

More information about the API in pcrejit(3).


Files

lighttpd_pcrejit.patch (2.28 KB) lighttpd_pcrejit.patch Lighttpd pcrejit patch mm, 2011-10-31 15:10
lighttpd_pcrejit_v2.patch (12.8 KB) lighttpd_pcrejit_v2.patch mm, 2011-11-02 15:48
lighttpd_pcrejit_v3.patch (15.6 KB) lighttpd_pcrejit_v3.patch mm, 2011-11-02 17:07
lighttpd_pcrejit_v4.patch (17.2 KB) lighttpd_pcrejit_v4.patch mm, 2011-11-02 21:23
Actions #1

Updated by mm almost 10 years ago

In the patch, I forgot to replace the last

#ifdef PCRE_CONFIG_JIT
with
 #ifdef PCRE_STUDY_JIT_COMPILE
to be on the safe side.

PCRE_CONFIG_JIT is used to test the availability of JIT support, as the following example shows:

int rc, jit_support;

(void) pcre_config(PCRE_CONFIG_JIT, &rc);
if (rc)
    jit_support=1;
else
    jit_support=0;
Actions #2

Updated by mm almost 10 years ago

Here is a more complete patch that also adds pcre_study() to mod_rewrite and other relevant modules.
Next step would be not using the machine stack but assigning an individual pcre_jit stack e.g. per module.

Actions #3

Updated by mm almost 10 years ago

This third version also includes a per-server common PCRE JIT stack of size 32kB-1024kB

Actions #4

Updated by darix almost 10 years ago

  • Status changed from New to Need Feedback

a few comments

  1. get rid of the ugly static ints
  2. make a server wide setting server.use-pcre-jit (see server.errorlog as example) to make it possible to disable the feature.
    the setting should warn the user if the he tries to enable it without support in their PCRE library. this also should make it possible to have all the #ifdef fun for this thing in one place.
  3. depending on your benchmarks, you can enable the setting by default.
Actions #5

Updated by mm almost 10 years ago

Ok, I have updated your patch according to your description. You cannot actually have the #ifdefs removed.
the macro PCRE_STUDY_JIT_COMPILE, and the functions pcre_assign_jit_stack(), pcre_jit_stack_alloc(), pcre_jit_stack_free, pcre_free_study() are otherwise not available and code won't compile (that's why I check for PCRE_CONFIG_JIT).

One problem that has raised is configparser.y - can you use srv.srvconf inside configparser.y? I guess not.
For now I have removed the code from there, but that is the last part where it is missing.

For starters the option is disabled by default.

Actions #6

Updated by stbuehler almost 10 years ago

Imho this patch should only be added, if you can provide benchmarks which show this is actually useful (as 1.4.x is a stable branch, i don't want to add features - and risk breaking something - without a good reason).

Then:
  1. imho the config option should be always available, but it should give a warning if the user enabled the option and pcre does not support it (it looks like even if the new api is present, jit still can be disabled)
  2. as the patch should only be added if we know it provides better performance, i suggest enabling the option by default if the new api is present and jit support is present.
  3. the regular expressions in the config file should be jit compiled too; so perhaps we should "re"-study the expressions after the config has been parsed (or move the study)
  4. darix did not ask you to get rid of all the #ifdef magic, but to put it in one place, which is certainly possible.
  5. the current src/configparser.y changes are useless
  6. the jit stack size(s) should be configurable (whatever those values mean, they look too large for embedded systems)
Actions #7

Updated by stbuehler over 9 years ago

  • Status changed from Need Feedback to Missing Feedback
  • Target version deleted (1.4.x)
Actions

Also available in: Atom