std.experimental.allocator.make should throw on out-of-memory

Alex Parrill via Digitalmars-d digitalmars-d at puremagic.com
Wed Apr 20 14:26:12 PDT 2016


On Wednesday, 20 April 2016 at 20:23:53 UTC, Era Scarecrow wrote:
>
>  The downside though is the requirement to throw may not be 
> necessary. Having a failed attempt at getting memory and 
> sleeping the program for 1-2 seconds before retrying could 
> succeed on a future attempt. For games this would be a failure 
> to have the entire game pause and hang until it acquires the 
> memory it needs, while non critical applications (say 
> compressing data for a backup) having it be willing to wait 
> wouldn't be a huge disadvantage (assuming it's not at the start 
> and already been busy for a while).

This would be best implemented in a "building block" allocator 
that wraps a different allocator and uses the `allocate` 
function, making it truly optional. It would also need a timeout 
to fail eventually, or else you possibly wait forever.

>  This also heavily depends on what type of memory you're 
> allocating. A stack based allocator (with fixed memory) 
> wouldn't ever be able to get you more memory than it has fixed 
> in reserve so immediately throwing makes perfect sense

True, if you are allocating from small pools then OOM becomes 
more likely. But most programs do not directly allocate from 
small pools; rather, they try to allocate from a small pool (ex. 
a freelist) but revert to a larger, slower pool when the smaller 
pool cannot satisfy a request. That is implemented using the 
building block allocators, which use the `allocate` method, not 
`make`.

> Although IF the memory could be arranged and a second attempt 
> made before deciding to throw could be useful (which assumes 
> not having direct pointers to the memory in question and rather 
> having an offset which is used. The more I think about it 
> though the less likely this would be).

This is the mechanism used for "copying" garbage collectors. They 
can only work if they can know about and alter all references to 
the objects that they have allocated, which makes them hard to 
use for languages with raw pointers like D.


More information about the Digitalmars-d mailing list