* stack overflow limit
@ 2011-05-04 17:04 Drew Adams
2011-05-04 18:51 ` Stefan Monnier
0 siblings, 1 reply; 4+ messages in thread
From: Drew Adams @ 2011-05-04 17:04 UTC (permalink / raw)
To: emacs-devel
Not a request or a suggestion. I'm just wondering about the stack size limit
(e.g. for regexp search, search.c).
Would it make sense to make it any bigger, given that machines nowadays are more
powerful and have more memory, or do you consider that pretty much all such
stack overflows (e.g. for regexp matching) are just due to poorly chosen
regexps?
Again, just wondering if it might be appropriate (time) to bump the stack limit.
(No, I don't have a particular use case or regexp in mind.)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: stack overflow limit
2011-05-04 17:04 stack overflow limit Drew Adams
@ 2011-05-04 18:51 ` Stefan Monnier
2011-05-04 20:43 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: Stefan Monnier @ 2011-05-04 18:51 UTC (permalink / raw)
To: Drew Adams; +Cc: emacs-devel
> Not a request or a suggestion. I'm just wondering about the stack size limit
> (e.g. for regexp search, search.c).
> Would it make sense to make it any bigger, given that machines
> nowadays are more powerful and have more memory, or do you consider
> that pretty much all such stack overflows (e.g. for regexp matching)
> are just due to poorly chosen regexps?
IIRC this depends on the OS stack size, which hasn't grown nearly as
fast as hardware resources.
Stefan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: stack overflow limit
2011-05-04 18:51 ` Stefan Monnier
@ 2011-05-04 20:43 ` Eli Zaretskii
2011-05-05 7:16 ` Andy Wingo
0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2011-05-04 20:43 UTC (permalink / raw)
To: Stefan Monnier; +Cc: drew.adams, emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 04 May 2011 15:51:22 -0300
> Cc: emacs-devel@gnu.org
>
> > Not a request or a suggestion. I'm just wondering about the stack size limit
> > (e.g. for regexp search, search.c).
> > Would it make sense to make it any bigger, given that machines
> > nowadays are more powerful and have more memory, or do you consider
> > that pretty much all such stack overflows (e.g. for regexp matching)
> > are just due to poorly chosen regexps?
>
> IIRC this depends on the OS stack size, which hasn't grown nearly as
> fast as hardware resources.
How much stack does Emacs have on a typical Unix or GNU machine these
days?
The value of re_max_failures we use now needs 4MB of stack on a 32-but
machine, twice as much on a 64-bit machine. We also need stack space
for GC. The result should be compared to what Emacs has and what it
can have.
`ulimit' seems to indicate we get 8MB of stack on an x86_64 GNU/Linux
system. On Windows, we tell the linker to reserve 8MB as well (but
the Windows build is a 32-bit build.)
Ultimately, the question is: should we increase the value of
re_max_failures?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: stack overflow limit
2011-05-04 20:43 ` Eli Zaretskii
@ 2011-05-05 7:16 ` Andy Wingo
0 siblings, 0 replies; 4+ messages in thread
From: Andy Wingo @ 2011-05-05 7:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Stefan Monnier, drew.adams, emacs-devel
On Wed 04 May 2011 22:43, Eli Zaretskii <eliz@gnu.org> writes:
> `ulimit' seems to indicate we get 8MB of stack on an x86_64 GNU/Linux
> system.
That varies per-system. Some distributions do not set a stack limit via
`ulimit'.
Andy
--
http://wingolog.org/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-05-05 7:16 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-05-04 17:04 stack overflow limit Drew Adams
2011-05-04 18:51 ` Stefan Monnier
2011-05-04 20:43 ` Eli Zaretskii
2011-05-05 7:16 ` Andy Wingo
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).