Thread (43 messages) 43 messages, 3 authors, 2021-01-24

Re: [PATCH 3/3] grep: stop using a custom JIT stack with PCRE v1

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2019-07-26 14:43:11

On Fri, Jul 26 2019, Carlo Arenas wrote:
On Fri, Jul 26, 2019 at 6:50 AM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
quoted
On Fri, Jul 26 2019, Carlo Arenas wrote:
quoted
since this moves PCRE1 out of the JIT fast path,
I think you're mostly replying to the wrong thread. None of the patches
I've sent disable PCRE v1 JIT, as the performance numbers show. The JIT
stack is resized, and for v2 some dead code removed.
I didn't mean JIT was disabled, but that we are calling now the regular
PCRE1 function which does UTF-8 validation (unlike the one used before)
quoted
quoted
introduces the regression where git grep will abort if there is binary
data or non UTF-8 text in the repository/log and should be IMHO hold
out until a fix for that can be merged.
You're talking about the kwset series, not this cleanup series.
a combination of both (as seen in pu) and that will also happen in next if
this series get merged there.

before this cleanup series, a git compiled against PCRE1 and not using
NO_LIBPCRE1_JIT will use the jit fast path function and therefore would
have no problems with binary or non UTF-8 content in the repository, but
will regress after.
I see. Yes you're right, I misread pcrejit(3) about how the "fast path
API" worked (or more accurately, misremembered). Yes, this is now a new
caveat.

I have some patches on top of next I'm about to send that hopefully make
this whole thing less of a mess.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help