Re: Segments

On Thu, 16 Jan 2025 18:12:46 -0000 (UTC)
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.  It is the latter which would need
to allocate on the stack.
 

The part about passing, including dynamic allocation, is what in C
called VM types.

But allocating them on the stack is an implementation detail.
Since Fortran 90, you can also do
 
  subroutine foo(n,m)
    integer, intent(in) :: n,m
    real, dimension(n,m) :: a
 
which will delcare the array a with the bounds of n and m.
(Fortran can also do dynamic memory allocation, so
 
  subroutine foo(n,m)
    integer, intent(in) :: n,m
    real, dimension(:,:), allocatable :: c
    allocate (c(n,m))
 
would also work, and also automatically release the memory).
 
Because Fortran users are used to large arrays, any good Fortran
compiler will also allocate a on the heap if it is too large.
 
 

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.

In user space it is just unfortunate tradition. Not in all languages,
BTW. In Go, for example, default stack is 1 GB, which is still small,
but not ridiculously small as 1 to 8 MB that are typical in C, C++,
Rust and I suppose Fortran.
However original point of discussion was kernel programming. In kernel
there are pretty good reasons in place why default stack is very small.
8-32 KB, I think. May be on Apple few times bigger, I didn't check.
The reason is that in many kernel contexts page fault not allowed, so
you have to allocate physical memory rather than just reserve address
space.

"To avoid infinite recursion" is not a valid reason, IMHO.
 

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.
 
If you have a memory allocation pattern like
 
  p1 = malloc(chunk_1);  /* Fill it */
  p2 = malloc(chunk_2);
  /* Use it */
  free (p2);
  p3 = malloc(chunk_3);
  /* Use it */
  free (p3)
  /* Use p1 */
 
There is a chance that p2 still pollutes the cache and parts of
p1 may have been removed unnecessarily.  This would not have been
the case p2 and p3 had been allocated on the stack.
 

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.