Hi David, > -----Original Message----- > From: David Zuelke [mailto:d...@heroku.com] > Sent: Monday, March 21, 2016 10:52 PM > To: Anatol Belski <anatol....@belski.net> > Cc: Christoph Becker <cmbecke...@gmx.de>; Pierre Joye > <pierre....@gmail.com>; PHP internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] PCRE JIT stack size limit > > On 21.03.2016, at 19:41, Anatol Belski <anatol....@belski.net> wrote: > > I've just pushed a fix for this issue, could you please check? A > > global stack space Is used in a thread safe manner. I was first > > setting max to 256K, then decreased it To 64K for now. My tests on > > Linux and Windows show your snippet passing, Travis is good as well. > > Just tested; that fix works for my specific test case, thanks! > > However, if I just increase the size of the JSON by adding a bunch of package > definitions, it starts failing again, so this really is just a temporary band-aid, and > we should consider falling back to retrying without JIT, or switching that off by > default in php.ini. > > The particular composer.json I showed is generated on deploy based on a > customers' composer.lock (to correctly resolve PHP versions and extensions to > be installed), and there will be a day when a customer with more dependencies > comes along (or maybe that's already happened and they just have not filed a > ticket), which means the 64k again won't be enough. > Thanks for the checks! Yeah, what you mention is clear, there can be some situation exhausting the values given, whatever they are. The max JIT stack size is 1mb.
What I'm suggesting to do is using a bit finer comb checking with the real life situations. Fe what would be the win for the user, either having to enable JIT by hand, or to disable it in a rare case. Currently, as for me, the latter seems still to be a more feasible option. At some point some due consideration could be reached, but I don't see the today's point as such. As long as we still handle over 99% of the usage cases with a simple JIT stack increase, it is IMHO more than balanced. The option of falling back to no JIT could be still kept in mind as it's most likely won't cause any compatibility issue. Thanks. Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
