[Mesa-dev] [PATCH] i965: Use new/delete instead of realloc() in brw_ir_allocator.h

[Eero Tamminen]

Hi,

On 02/11/2015 08:45 PM, Kenneth Graunke wrote:
> On Wednesday, February 11, 2015 04:56:56 PM Juha-Pekka Heikkila wrote:
>> There is no error path available thus instead of giving
>> realloc possibility to fail use new which will never
>> return null pointer and throws bad_alloc on failure.
...
> Okay, I'll go ahead and say what Matt and Jason were probably thinking:
>
> NAK.
>
> I'm not against using new/delete in general, but using realloc to double
> the size of arrays is a pattern we use all over the codebase.  I don't
> see any reason not to use that same pattern here.  Plus, the old code
> was 2 lines of code...and now it's 8 lines of code, for no real benefit.
>
> Most idiomatic C++ code I've seen would just some kind of flexible array
> class, like std::vector, rather than open coding this.  So, we're
> already divergent from C++ best practices, and instead are following the
> typical C idiom.  This is neither.
>
> In fact, your new code is more likely to fail than the old one: instead
> of growing the array from size N to size 2*N---which realloc may be able
> to do in-place---you're briefly keeping both around, using N+2*N=3*N
> space.  If realloc failed, this would absolutely fail too.
>
> If we compiled without exceptions, this would crash in an identical
> manner - no actual error handling is done here.  With exceptions, it's
> not much better - we throw an exception all the way outside of libGL and
> back to the application (since we sure don't handle those), leaving our
> work in some unknown state.

Qt had at least earlier nasty habit of re-throwing uncaught exceptions
in its main loop, which completely hid the cause for a random
application crash.  There may be other SW packages that do similarly
silly things.  Core dump at place where the problem first occurs is
IMHO much nicer.


> Plus, as has been repeatedly mentioned - malloc doesn't fail if you're
> out of memory - it only fails if you're out of virtual address space.

A valid 3D use-case for that is Steam games.  Majority of them are
32-bit only, so they can run out of memory & address space without
system being low on memory.


	- Eero

PS. In previous life I bumped into another, funny use-case for that,
programs that leak joinable threads (don't join them after exit).

We were wondering how programs could generate GB sized core dumps on
128MB device, until we noticed that they run out of 32-bit address
space because they had too many threads...  Default Linux thread stack
size (8MB) was quickly lowered after that and whole system tracking
added for thread leakage. :-)