Oak on Solaris currently mallocs its thread stacks. A user thread stack is 400K by
default, and Oak tends to have a fair number of user threads going if it's doing
anything significant. These things being malloced means uses up a lot of brk space.
It's typically not going to be needed -- thread stacks are normally very small.
400K was from the days when both the Oak stack and the C stack were in the
thread stack (and aimed at Oak running the Star7 demo in 4M)!
On Solaris we should go back to an arrangement where we mmap the stacks from
/dev/zero, so we only pay for what memory we need. This code had been written for
the Solaris native threads port, but was backed out: libthread collects dead threads
with a reaper process that seems to expect the stacks to be there, so I didn't
seem to be able to free them reliably. The code was never included in the
reorganized Green system but could be adapted to it.
Where we have to malloc thread stacks we should consider bringing the default size
of user thread stacks down. Granted, this is slightly less safe, but our current safety
comes at a high cost for the average user. If someone really needs larger stacks the
default can be overridden.
It would be interesting to know how much thread stack current apps use, and as
more significant apps are developed how the use grows. That's the sort of info we
should base our default sizes on.
default, and Oak tends to have a fair number of user threads going if it's doing
anything significant. These things being malloced means uses up a lot of brk space.
It's typically not going to be needed -- thread stacks are normally very small.
400K was from the days when both the Oak stack and the C stack were in the
thread stack (and aimed at Oak running the Star7 demo in 4M)!
On Solaris we should go back to an arrangement where we mmap the stacks from
/dev/zero, so we only pay for what memory we need. This code had been written for
the Solaris native threads port, but was backed out: libthread collects dead threads
with a reaper process that seems to expect the stacks to be there, so I didn't
seem to be able to free them reliably. The code was never included in the
reorganized Green system but could be adapted to it.
Where we have to malloc thread stacks we should consider bringing the default size
of user thread stacks down. Granted, this is slightly less safe, but our current safety
comes at a high cost for the average user. If someone really needs larger stacks the
default can be overridden.
It would be interesting to know how much thread stack current apps use, and as
more significant apps are developed how the use grows. That's the sort of info we
should base our default sizes on.