Re: Segments

Thomas Koenig <tkoenig@netcologne.de> wrote:

Waldek Hebisch <antispam@fricas.org> schrieb:

David Brown <david.brown@hesbynett.no> wrote:

On 16/01/2025 13:35, Michael S wrote:

On Thu, 16 Jan 2025 12:36:45 +0100
David Brown <david.brown@hesbynett.no> wrote:
 

On 15/01/2025 21:59, Thomas Koenig wrote:

Michael S <already5chosen@yahoo.com> schrieb:

On Wed, 15 Jan 2025 18:00:34 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
 

>

As you can guess, in kernel drivers VLA are unwelcome.

 
I can imagine that they are - but I really don't understand why.  I've
never understood why people think there is something "dangerous" about
VLAs, or why they think using heap allocations is somehow "safer".

>
VLA normally allocate on the stack.

 
You can pass them as VLAs (which Fortran has had since 1958)
or you can declare them.

As explained in other post in C VLA means allocation, passing
is VMT.

Which at first glance look
great.  But once one realize how small are stacks in modern
systems (compared to whole memory), this no longer looks good.

 
Stacks are small because OS people make them small, not because of
a valid technical reason that has ever been explained to me.
"To avoid infinite recursion" is not a valid reason, IMHO.

On multiuser machine there is some point in it: you do not
want buggy student program to cause thrashing.  In other
words you need stack limit that is some smallish fraction
of real memory.  With virtual memory heap allocations bigger
than RAM work fine.

There is good reason for small kernel stacks: it is used to
handle interupts, including page faults, so must be real
memory.  Since each thread needs its own kernel stack, bigger
stack would mean quite a lot of memory use.

In 32-bit era there was also valid reason for small user stacks.
Namely, one needs to pre-allocate address space for stack(s) and
with lots of threads there is not enough address space to give
sizeable stack to each thread.

IIUC popular current processors are still quite far from having
64-bit virtual address space, so there is still reason to limit
stack size, simply limit can be much bigger than on 32-bit
systems.

There is also another issue: stack allocations become invalid
when routine doing allocation returns.  Which depending on
application may be unacceptable.  So, reuse of code doing
stack allocation is tricky, while for heap allocation simple
reference count may be ehough to ensure that allocation is
freed when nobody uses given area.  Consequently, there is
tendency to use heap allocation to allow more flexible use
patterns.  With more use of heap allocation there is less
use of stack allocation and big stacks are considered
unnecessary.

Basically, to use VLA one needs rather small bound on maximal
size of array.  Given such bound always allocating maximal
size is simpler.  Without _small_ bound on size heap is
safer, as it is desined to handle also big allocations.

 
Allocating data on the stack promotes cache locality, which can
increase performance by quite a lot.

Sure.

In the past I was a fan of VLA and stack allocation in general.
But I saw enough bug reports due to programs exceeding their
stack limits that I changed my view.

 
Stack limits are artificial, but
 

>
I do not know about Windows, but IIUC in some period Linux limit
for kernel stack was something like 2 kB (single page shared
with some other per-process data structures).  I think it
was increased later, but even moderate size arrays are
unwelcame on kernel stack due to size limits.

 
... for kernels maybe less so.

--
                              Waldek Hebisch