Re: OCTAVE_LOCAL_BUFFER

[John W. Eaton]

On  6-Dec-2008, Jaroslav Hajek wrote:

| OK, the new code for OCTAVE_LOCAL_BUFFER is uploaded. It appears that
| octave_fcn_handle::load_binary relied on the old behaviour of using
| std::vector (which always default-initializes elements). I believe
| that OCTAVE_LOCAL_BUFFER was not intended to be initialized, so I
| fixed the offending code.

Right, it was intended as uninitialized space.

| The current state is as said above: a buffer < 8K is allocated on the
| stack (if dynamic stack arrays are supported), otherwise via normal
| new[] allocation.
| I'm not sure 8K is the best constant, but stack is a very limited
| resource, and its overflow is typically unrecoverable, so I tried to
| be conservative...

I don't know of a good way to decide whether that will cause trouble.

| There is a more sophisticated optimization of local buffers possible.
| Since they have a FIFO semantics, it is possible to allocate big
| chunks (say, 16 MB) in a stack-like manner and serve local buffers
| from them. Obstacks from the GNU C library are based on the same idea
| (except that using obstacks would be an overkill, because we would
| need only a small subset of their functionality).
| 
| opinions?

That would probably be a better way to go, as it would avoid any stack
resource limitations.  Also, we could grow the buffer (or add more
buffers to a list) as needed.

I'm not sure it is necessary to do this just now, but given the number
of uses of OCTAVE_LOCAL_BUFFER, we may see some complaints about
Octave crashing due to running out of stack space without it.  If we
do, then I think we'll have to either disable the local stack
optimization or implement something like you are suggesting.

jwe