Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #68773 > unrolled thread

alloca()-support

Started byBonita Montero <Bonita.Montero@gmail.com>
First post2019-09-30 14:02 +0200
Last post2019-10-05 14:08 -0700
Articles 20 on this page of 110 — 21 participants

Back to article view | Back to comp.lang.c++

Contents

  alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 14:02 +0200
    Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-09-30 07:02 -0700
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:09 +0200
        Re: alloca()-support Bo Persson <bo@bo-persson.se> - 2019-09-30 17:29 +0200
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 17:33 +0200
      Re: alloca()-support gazelle@shell.xmission.com (Kenny McCormack) - 2019-09-30 16:26 +0000
    Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:12 +0300
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:16 +0200
        Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:30 +0300
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 16:44 +0200
            Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 00:36 +0300
              Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:28 +0200
                Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 16:08 +0300
                  Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 15:42 +0200
      Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 14:30 +0000
        Re: alloca()-support Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-09-30 17:33 +0300
          Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-09-30 16:56 +0200
      Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-09-30 15:29 +0000
        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 17:31 +0200
          Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 07:03 +0000
            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 10:57 +0200
              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 18:49 +0000
                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:20 +0200
                  Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 20:39 +0000
                  Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:15 +0000
                    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:28 +0200
                      Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:29 +0000
      Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-09-30 11:14 -0700
    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:04 +0200
      Re: alloca()-support William Ahern <william@25thandClement.com> - 2019-09-30 11:01 -0700
        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:19 +0200
      Re: alloca()-support Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-30 22:26 +0300
        Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 19:46 +0000
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:32 +0200
        Re: alloca()-support Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-01 09:08 +0300
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 08:35 +0200
    Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 18:48 +0200
      Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:51 +0200
        Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 18:55 +0200
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 18:58 +0200
            Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 19:53 +0200
              Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-09-30 11:13 -0700
              Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 19:38 +0000
                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:41 +0200
                  Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 15:19 +0000
                    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 17:31 +0200
                      Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-01 18:58 +0000
                        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:24 +0200
                          Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:28 +0000
                            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:30 +0200
                              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:36 +0000
                                Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:01 +0200
                              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-02 04:42 +0000
                                Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:10 +0200
                                  Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:13 +0200
                      Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 21:10 +0200
                        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 21:25 +0200
                          Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-01 20:44 +0000
                          Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 23:26 +0200
                            Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-01 21:08 -0600
                              Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:19 +0200
                            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 06:39 +0200
                              Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-02 10:34 +0200
                          Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:14 +0200
                      Re: alloca()-support Mel <mel@zzzzz.com> - 2019-10-02 15:18 +0200
                        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-02 15:21 +0200
                          Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 04:09 +0000
                            Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 07:48 +0200
                              Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 05:49 +0000
                                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 07:52 +0200
                                  Re: alloca()-support Melzzzzz <Melzzzzz@zzzzz.com> - 2019-10-03 06:46 +0000
                                    Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-03 10:59 +0200
                Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 13:39 +0200
                  Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-03 13:23 +0000
                  Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-03 15:38 +0200
                    Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-10-03 14:51 +0000
                      Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-04 09:49 +0200
                    Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 21:47 +0200
                      Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-04 09:53 +0200
                    Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-10-03 21:52 +0200
              Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:39 +0200
          Re: alloca()-support James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-30 21:36 -0400
        Re: alloca()-support Philipp Klaus Krause <pkk@spth.de> - 2019-09-30 19:14 +0200
          Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 19:16 +0200
            Re: alloca()-support Robert Wessel <robertwessel2@yahoo.com> - 2019-10-01 00:18 -0500
              Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 07:43 +0200
              Re: alloca()-support Keith Thompson <kst-u@mib.org> - 2019-10-01 02:42 -0700
                Re: alloca()-support James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-10-01 08:11 -0400
                Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-01 14:53 +0200
        Re: alloca()-support scott@slp53.sl.home (Scott Lurndal) - 2019-09-30 17:52 +0000
      Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-09-30 11:20 -0600
        Re: alloca()-support Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-30 19:42 +0200
          Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 20:02 +0200
        Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 19:54 +0200
          Re: alloca()-support Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-09-30 14:28 -0600
            Re: alloca()-support David Brown <david.brown@hesbynett.no> - 2019-10-01 09:38 +0200
        Re: alloca()-support Soviet_Mario <SovietMario@CCCP.MIR> - 2019-09-30 20:01 +0200
          Re: alloca()-support Manfred <noname@add.invalid> - 2019-10-01 17:45 +0200
    Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-02 00:03 -0700
      Re: alloca()-support Paavo Helde <myfirstname@osa.pri.ee> - 2019-10-02 11:30 +0300
      Re: alloca()-support Ian Collins <ian-news@hotmail.com> - 2019-10-02 21:34 +1300
        Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-02 01:36 -0700
          Re: alloca()-support Ian Collins <ian-news@hotmail.com> - 2019-10-02 21:41 +1300
            Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-02 02:28 -0700
    Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-02 02:35 -0700
      Re: alloca()-support Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-10-02 02:43 -0700
      Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-02 16:26 +0300
        Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-02 12:33 -0700
          Re: alloca()-support Anton Shepelev <anton.txt@gmail.com> - 2019-10-03 01:47 +0300
            Re: alloca()-support "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-10-05 14:08 -0700

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#68840

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-10-01 10:57 +0200
Message-ID<qmv4dd$kv6$1@news.albasani.net>
In reply to#68834
>>> VLA elliminates need for alloca...

>> C++ hasn't VLAs.

> No, neiter has alloca...

Doesn't matter since most compilers support alloca().

[toc] | [prev] | [next] | [standalone]

#68859

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2019-10-01 18:49 +0000
Message-ID<ndNkF.453835$665.280913@fx28.am4>
In reply to#68840
On 2019-10-01, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> VLA elliminates need for alloca...
>
>>> C++ hasn't VLAs.
>
>> No, neiter has alloca...
>
> Doesn't matter since most compilers support alloca().

Which one does not supports VLA and supports alloca?
>


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [prev] | [next] | [standalone]

#68865

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-10-01 21:20 +0200
Message-ID<qn08uk$5m8$1@news.albasani.net>
In reply to#68859
>>>> C++ hasn't VLAs.

>>> No, neiter has alloca...

>> Doesn't matter since most compilers support alloca().

> Which one does not supports VLA and supports alloca?

I'm using C++ and C++ hasn't VLAs.
But almost any C++-compiler supports alloca().

[toc] | [prev] | [next] | [standalone]

#68871

Fromscott@slp53.sl.home (Scott Lurndal)
Date2019-10-01 20:39 +0000
Message-ID<jQOkF.1996$9v2.1080@fx31.iad>
In reply to#68865
Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>> C++ hasn't VLAs.
>
>>>> No, neiter has alloca...
>
>>> Doesn't matter since most compilers support alloca().
>
>> Which one does not supports VLA and supports alloca?
>
>I'm using C++ and C++ hasn't VLAs.

g++ does, as an extension.

[toc] | [prev] | [next] | [standalone]

#68877

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2019-10-02 04:15 +0000
Message-ID<PvVkF.613952$Nw3.15300@fx40.am4>
In reply to#68865
On 2019-10-01, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> C++ hasn't VLAs.
>
>>>> No, neiter has alloca...
>
>>> Doesn't matter since most compilers support alloca().
>
>> Which one does not supports VLA and supports alloca?
>
> I'm using C++ and C++ hasn't VLAs.
> But almost any C++-compiler supports alloca().
Any C++11 compil.er that supports C99 also supports VLA, I bet...

-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [prev] | [next] | [standalone]

#68880

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-10-02 06:28 +0200
Message-ID<qn1929$hai$2@news.albasani.net>
In reply to#68877
>> I'm using C++ and C++ hasn't VLAs.
>> But almost any C++-compiler supports alloca().

> Any C++11 compil.er that supports C99 also supports VLA, I bet...

Boy, you're such a mega-idiot.

[toc] | [prev] | [next] | [standalone]

#68881

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2019-10-02 04:29 +0000
Message-ID<5JVkF.568896$bS1.152331@fx13.am4>
In reply to#68880
On 2019-10-02, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>
>>> I'm using C++ and C++ hasn't VLAs.
>>> But almost any C++-compiler supports alloca().
>
>> Any C++11 compil.er that supports C99 also supports VLA, I bet...
>
> Boy, you're such a mega-idiot.
>
Look into mirror...

-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [prev] | [next] | [standalone]

#68813

FromKeith Thompson <kst-u@mib.org>
Date2019-09-30 11:14 -0700
Message-ID<lna7al3b3r.fsf@kst-u.example.com>
In reply to#68782
Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
[...]
> At least, it is absent from TCC, but the specific compilers
> are of no importance.

I just used alloca() with tcc on my system.  It generates a call to the
implementation in the GNU C library.  (With gcc, calls to alloca() are
inlined.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#68796

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-09-30 18:04 +0200
Message-ID<qmt93c$4sg$1@news.albasani.net>
In reply to#68773
I just came across another issue:
With my primary compiler theres's an internal function called __chkstk
called when I do alloca. This function is usually called when there are
more than a page full of variables in the stack-frame. That's because
Windows recognizes the need for more stack space only through touching
the next unmapepd page down the stack. So why hasn't MS so be so clever
as to design Windows that it would also recoginize noncontignous acces-
ses to the stack-pages? Are these pages handled are like being over-
comitted?

[toc] | [prev] | [next] | [standalone]

#68814

FromWilliam Ahern <william@25thandClement.com>
Date2019-09-30 11:01 -0700
Message-ID<chs96g-nm41.ln1@wilbur.25thandClement.com>
In reply to#68796
Bonita Montero <Bonita.Montero@gmail.com> wrote:
> I just came across another issue:
> With my primary compiler theres's an internal function called __chkstk
> called when I do alloca. This function is usually called when there are
> more than a page full of variables in the stack-frame. That's because
> Windows recognizes the need for more stack space only through touching
> the next unmapepd page down the stack. So why hasn't MS so be so clever
> as to design Windows that it would also recoginize noncontignous acces-
> ses to the stack-pages? Are these pages handled are like being over-
> comitted?

The compiler does this to ensure the alloca'd region doesn't extend past the
stack guard page. The kernel can handle noncontiguous stack access, but what
happens if your block extends *past* the stack into the dynamic heap region?

See https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash
and https://lwn.net/Articles/725832/ for more info

[toc] | [prev] | [next] | [standalone]

#68827

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-10-01 07:19 +0200
Message-ID<qmunlc$rsu$1@news.albasani.net>
In reply to#68814
>> I just came across another issue:
>> With my primary compiler theres's an internal function called __chkstk
>> called when I do alloca. This function is usually called when there are
>> more than a page full of variables in the stack-frame. That's because
>> Windows recognizes the need for more stack space only through touching
>> the next unmapepd page down the stack. So why hasn't MS so be so clever
>> as to design Windows that it would also recoginize noncontignous acces-
>> ses to the stack-pages? Are these pages handled are like being over-
>> comitted?

> The compiler does this to ensure the alloca'd region doesn't extend past
> the stack guard page.

1. Not the compiler does do this but the OS.
2. The OS could do this with a single guard-page or maybe by reserving
    a larger number of pages at the end of the stack.

> The kernel can handle noncontiguous stack access, ...

No, It can't as I said. I'm talking about Windows.

[toc] | [prev] | [next] | [standalone]

#68816

FromPaavo Helde <myfirstname@osa.pri.ee>
Date2019-09-30 22:26 +0300
Message-ID<qmtksj$kpc$1@dont-email.me>
In reply to#68796
On 30.09.2019 19:04, Bonita Montero wrote:
> I just came across another issue:
> With my primary compiler theres's an internal function called __chkstk
> called when I do alloca. This function is usually called when there are
> more than a page full of variables in the stack-frame. That's because
> Windows recognizes the need for more stack space only through touching
> the next unmapepd page down the stack. So why hasn't MS so be so clever
> as to design Windows that it would also recoginize noncontignous acces-
> ses to the stack-pages?

I guess this would mean setting up e.g. 64 guard pages instead of one or 
two, and most of those pages would remain untouched and unused 
(many-many service threads use extremely little stack space).

Also, this would not avoid the need for checks at alloca(), it would 
still need to check that the allocation fits in the total free space of 
the current stack.

 > Are these pages handled are like being over-comitted?

As a little experiment shows, in Windows the virtual address space for 
the stack is reserved, but not committed. Strictly speaking, you cannot 
over-commit something which is not committed. But I can see how this 
might feel similar.

[toc] | [prev] | [next] | [standalone]

#68819

Fromscott@slp53.sl.home (Scott Lurndal)
Date2019-09-30 19:46 +0000
Message-ID<uYskF.22051$XA2.15559@fx05.iad>
In reply to#68816
Paavo Helde <myfirstname@osa.pri.ee> writes:
>On 30.09.2019 19:04, Bonita Montero wrote:
>> I just came across another issue:
>> With my primary compiler theres's an internal function called __chkstk
>> called when I do alloca. This function is usually called when there are
>> more than a page full of variables in the stack-frame. That's because
>> Windows recognizes the need for more stack space only through touching
>> the next unmapepd page down the stack. So why hasn't MS so be so clever
>> as to design Windows that it would also recoginize noncontignous acces-
>> ses to the stack-pages?
>
>I guess this would mean setting up e.g. 64 guard pages instead of one or 

A "guard page" is just a PTE with the valid bit reset.  In most cases,
that PTE is there regardless of whether that page is actually being
used (or has been allocated).

The OS can look at the faulting address vis-a-vis the stack region allocated at
process creation and heuristically determine if the stack should be
extended to include that address.

>two, and most of those pages would remain untouched and unused 
>(many-many service threads use extremely little stack space).

Virtual memory is a rare commodity on 32-bit split virtual address
space systems - it's the virtual address space that is consumed by
guard pages; and often the stack grows down towards the heap, allocation
a sufficiently large VLA or alloca() may corrup the heap if the OS can't
distinguish beween the accesses (which is likely).

[toc] | [prev] | [next] | [standalone]

#68828

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-10-01 07:32 +0200
Message-ID<qmuoe6$bac$1@news.albasani.net>
In reply to#68796
> I just came across another issue:
> With my primary compiler theres's an internal function called __chkstk
> called when I do alloca. This function is usually called when there are
> more than a page full of variables in the stack-frame. That's because
> Windows recognizes the need for more stack space only through touching
> the next unmapepd page down the stack. So why hasn't MS so be so clever
> as to design Windows that it would also recoginize noncontignous acces-
> ses to the stack-pages? Are these pages handled are like being over-
> comitted?

I just wrote a little program:

1. #include <Windows.h>
2. #include <iostream>
3. #include <thread>
4. #include <mutex>
5. #include <vector>
6. #include <cstddef>
7. #include <functional>
8.
9. using namespace std;
10.
11. int main()
12. {
13.     size_t const  ALLOCSIZE = (size_t)1 << 30;
14.     void         *p = VirtualAlloc( nullptr, ALLOCSIZE, MEM_RESERVE 
| MEM_COMMIT, PAGE_READWRITE );
15.     memset( p, 0, ALLOCSIZE );
16.
17.     auto threadFn = []( mutex &mtx, condition_variable &cv, bool 
&start )
18.     {
19.         auto getSignal = []( mutex &mtx, condition_variable &cv, 
bool &start )
20.         {
21.             unique_lock<mutex> ul( mtx );
22.             while( !start )
23.                 cv.wait( ul );
24.         };
25.         getSignal( ref( mtx ), ref( cv ), ref( start ) );
26.         __try
27.         {
28.             size_t const PAGESIZE = 0x1000;
29.             char volatile c[1], *p;
30.             for( p = c; ; *p, p -= PAGESIZE );
31.         }
32.         __except( EXCEPTION_EXECUTE_HANDLER )
33.         {
34.         }
35.         Sleep( INFINITE );
36.     };
37.     mutex              mtx;
38.     condition_variable cv;
39.     bool               start = false;
40.     vector<thread>     vt;
41.
42.     for( size_t i = 0; i != 1000; ++i )
43.         vt.emplace_back( threadFn, ref( mtx ), ref( cv ), ref( start 
) );
44.     {
45.         unique_lock<mutex> ul( mtx );
46.         start = true;
47.         cv.notify_all();
48.     }
49.
50.     Sleep( INFINITE );
51. }
52.

If I stop at line 15, I can see with the Process Explorer that the
virtual size as well as the private bytes of the process is raised
by 1GB. So There's no overcommit. The memset at line 15 doesn't
change this.
Then I spawn 1.000 threads and they first gonna wait for a condvar.
The threads get their standard threadsize set by the linker, which
is 1MB. At the point where they wait the virtual size of the pro-
cess is raised by about 1GB, but the private size is raised only
a small amount; so there's definitely a differnce in the commit
-behaviour between stack-allocation and VirtualAlloc / MEM_RESERVE
| MEM_COMMIT. When I waken the threads the read the whole stack
down to the guard page and the access to this page is catched by
a SEH-handler (I had to pack the waiting-part in a lambda because
I can't use functions with unwind-handlers that are using SEH).
So Windows is definitely overcommitting stacks.

[toc] | [prev] | [next] | [standalone]

#68832

FromPaavo Helde <myfirstname@osa.pri.ee>
Date2019-10-01 09:08 +0300
Message-ID<qmuqhf$a8m$1@dont-email.me>
In reply to#68828
On 1.10.2019 8:32, Bonita Montero wrote:

>  so there's definitely a differnce in the commit
> -behaviour between stack-allocation and VirtualAlloc / MEM_RESERVE
> | MEM_COMMIT.

Yes, it looks like the whole stack space is reserved with MEM_RESERVE, 
but is not committed with MEM_COMMIT.

> When I waken the threads the read the whole stack
> down to the guard page and the access to this page is catched by
> a SEH-handler

No, what happens that the guard page is moved through the whole stack 
until it reaches the end of it. The purpose of the guard page approach 
is exactly to avoid the need to commit extra stack space until it 
becomes needed.

> So Windows is definitely overcommitting stacks.

You cannot over-commit something what is not committed.

[toc] | [prev] | [next] | [standalone]

#68833

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-10-01 08:35 +0200
Message-ID<qmus3u$817$1@news.albasani.net>
In reply to#68832
>> When I waken the threads the read the whole stack
>> down to the guard page and the access to this page is catched by
>> a SEH-handler

> No, what happens that the guard page is moved through the whole stack 
> until it reaches the end of it. ...

The guard-page will stop moving at the end.

>> So Windows is definitely overcommitting stacks.

> You cannot over-commit something what is not committed.

This is a flavour of overcommitting because I get a commit by touching
a page and the application will crash if the "dynamic commmit" fails.

[toc] | [prev] | [next] | [standalone]

#68798

FromSoviet_Mario <SovietMario@CCCP.MIR>
Date2019-09-30 18:48 +0200
Message-ID<qmtbkq$pmp$1@dont-email.me>
In reply to#68773
On 30/09/2019 14:02, Bonita Montero wrote:
> I know alloca() neither is an official part of the C nor C++ 
> program-
> ming-language. But I use it for performance-reasons. Can 
> anyone name
> compilers that don't support alloca()?


sorry, mine is not an answer but a related question

Since when (if at any time) was variable size automatic 
array supported ?

I mean a temporary array local to a function whose size 
becomes known only at runtime (seems to me a generalization 
of variadic functions, which, too, does not know at compile 
time how much stack space will consume).

If implemented, It seems equivalent to alloca () ... is it 
there some limitation then in ORDER of automatic variable 
creations ?

I mean, im my simple mind I'd guess such variable size 
should follow all "sure" (known sized) variabiles and not to 
exceed one single dynamic sized variable (or at least to 
avoid strange and heavy overhead in access, not just _ESP, _EBP)

a single variable array on stack with no further variables 
does not seem that difficult to implement, or am I wrong ?

-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#68799

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-09-30 18:51 +0200
Message-ID<qmtbqv$ttm$1@news.albasani.net>
In reply to#68798
> Since when (if at any time) was variable size automatic array supported ?

Since C99.

[toc] | [prev] | [next] | [standalone]

#68800

FromSoviet_Mario <SovietMario@CCCP.MIR>
Date2019-09-30 18:55 +0200
Message-ID<qmtc2o$pmp$4@dont-email.me>
In reply to#68799
On 30/09/2019 18:51, Bonita Montero wrote:
>> Since when (if at any time) was variable size automatic 
>> array supported ?
> 
> Since C99.
> 

for curiosity, this feature has one or more of the 
limitations I feared ... or even none of them ?



-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#68801

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-09-30 18:58 +0200
Message-ID<qmtc6v$uk5$1@news.albasani.net>
In reply to#68800
>>> Since when (if at any time) was variable size automatic array 
>>> supported ?

>> Since C99.

> for curiosity, this feature has one or more of the limitations I feared 
> ... or even none of them ?

Yes, you could run out of stack-space, maybe hitting a guard-page
in the best case so that you wouldn't corrupt any other data.

[toc] | [prev] | [next] | [standalone]

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

Back to top | Article view | comp.lang.c++

csiph-web