Change the name of ArrayBoundsException in druntime

[Sean Kelly]

Denis Koroskin wrote:
> 
> I think that OutOfMemoryException should *not* be recoverable. Instead, 
> language should provide some hookable callback (like 
> onOutOfMemoryError()) which is called when memory limit is reached so 
> that program may free some unused memory (which is held by user since it 
> is not garbage-collected) and tries to allocate the memory again without 
> failure (return true from callback). User might decide to re-throw some 
> other kind of *exception*, like NotEnoughMemoryException(), to catch and 
> recover, or pass it (return false from callback) which in turn will 
> finally throw OutOfMemoryError().

This is a fair point, but how does one implement this safely?  Let's say 
for the sake of argument that onOutOfMemoryError() can be hooked by the 
user and may try to recover.  Now:

     auto x = new int[BIG_NUMBER];

Let's say that gc_malloc() is implemented like so:

     void* gc_malloc( size_t sz )
     {
         void* ptr;
         do
         {
             ptr = doMalloc(sz);
             if( ptr is null )
                 onOutOfMemoryError();
         } while( ptr is null );
         return ptr;
     }

Now let's assume that the first attempted allocation fails and 
onOutOfMemoryError() frees some memory rather than throwing so the 
allocation is attempted again.  But BIG_NUMBER is so darn big that the 
allocation fails again.  And once again onOutOfMemoryError() tries to 
free some memory and returns instead of throwing.  Is there any way to 
structure the recovery mechanism to avoid this situation given that 
onOutOfMemoryError() has no idea that it's being called in such a loop? 
  gc_malloc() could certainly give up and throw after a certain number 
of failed attempts, but putting the onus on the caller of 
onOutOfMemoryError() to deal with this situation is not reasonable in my 
opinion.


Sean