Re: [PATCH 3/3] grep: stop using a custom JIT stack with PCRE v1
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Jul 26, 2019, 14:43 UTC
- Message-ID
- <87ftms7t6s.fsf@evledraar.gmail.com>
- In-Reply-To
- <CAPUEsphZJ_Uv9o1-yDpjNLA_q-f7gWXz9g1gCY2pYAYN8ri40g@mail.gmail.com>
On Fri, Jul 26 2019, Carlo Arenas wrote:
Show 27 quoted lines
> On Fri, Jul 26, 2019 at 6:50 AM Ævar Arnfjörð Bjarmason > <avarab@gmail.com> wrote: >> >> On Fri, Jul 26 2019, Carlo Arenas wrote: >> >> > 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) > >> > 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.