This is the mail archive of the
java-prs@gcc.gnu.org
mailing list for the Java project.
[Bug libgcj/36218] [4.4 regression] libgcj causes stack overflow in jc1.exe
- From: "dannysmith at users dot sourceforge dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: java-prs at gcc dot gnu dot org
- Date: 13 May 2008 03:52:56 -0000
- Subject: [Bug libgcj/36218] [4.4 regression] libgcj causes stack overflow in jc1.exe
- References: <bug-36218-8837@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #2 from dannysmith at users dot sourceforge dot net 2008-05-13 03:52 -------
(In reply to comment #0)
> What negative consequences does increasing the default [stack]
> allocation have?
Minimal really, for a single threaded program like jc1.exe. We are just
reserving address space not actual memory. In a multithreaded app, each thread
reserves the same amount of address space as the primary thread (by default,
but the default can be overiden), so too high a stack reserve for main thread
can limit what is available for others.
Is it possible to adjust this limit at runtime, perhaps as
> needed?
>
No, not for main thread. It is built into the program header on MS windows.
GNAT also bumps stack reserve to 32 MB for "non-tasking" apps. See
system-mingw.ads.
In old days, 32 MB was default for win32 in gnu ld.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218