When I was interested in D some time ago, I believe GC was aborting the application on allocation failures. Is that still the case today? I am looking into using D for my new application, but I need some guarantees that I can at least save some critical data, when such thing happens, perhaps freeing some stuff that is not really needed for the saving part (e.g. I could destroy GUI, free all saved unmodified documents and after that proceed to save unsaved changes to temporary file of some kind (even unbuffered as i may not have enough memory for a buffer). This is essential for me, that I am able to do it, that there is a change to handle such situation. The application will run on a system with over-commit disabled, so that (C) malloc can correctly report failures. Is it currently possible? Will it be possible in a near future?

I could use malloc directly for such data and check its return values, but it won't save me when there would be enough memory and while after that GC will fail on something else and crash my application.

I was also thinking about using rust for it, but for this very same reason I can't (rust aborts() almost everywhere on allocation failures).

Since you want such fine grained control, you probably don't want to use the GC to allocate with.

Take a look at [0].
That should give you the fine grained control you desire.

Most importantly make, makeArray, expandArray, shrinkArray and dispose.
You would need to be a bit careful with some language features like new to make sure you don't use them in favor of this. Keep in mind you won't be using the GC to deallocate with unless you add it to it (addRoot).

[0] http://dlang.org/phobos/std_experimental_allocator.html

On Sunday, 14 February 2016 at 12:10:34 UTC, Jardík wrote:
> When I was interested in D some time ago, I believe GC was aborting the application on allocation failures. Is that still the case today? I am looking into using D for my new application, but I need some guarantees that I can at least save some critical data, when such thing happens, perhaps freeing some stuff that is not really needed for the saving part (e.g. I could destroy GUI, free all saved unmodified documents and after that proceed to save unsaved changes to temporary file of some kind (even unbuffered as i may not have enough memory for a buffer). This is essential for me, that I am able to do it, that there is a change to handle such situation. The application will run on a system with over-commit disabled, so that (C) malloc can correctly report failures. Is it currently possible? Will it be possible in a near future?
>
> [...]

Allocation failures throw errors such as onOutOfMemoryError which are meant to terminate the program (see the distinction between errors and exceptions in D) but I guess if you really need to you could catch it and save your data before exiting.

But if I couldn't use GC and do all allocations and deallocations manually, I wouldn't even be able to use exceptions and there would also no longer be much reason to write it in D. I did some searching and came into discussion and there found out that in case of an error thrown, D just forcibly unwinds the stack without running destructors or scope guards. Is that true? Can I even catch that Error?

On Tuesday, 16 February 2016 at 17:15:17 UTC, Jardík wrote:
> But if I couldn't use GC and do all allocations and deallocations manually, I wouldn't even be able to use exceptions and there would also no longer be much reason to write it in D.

You can use exceptions without the GC and D offers a lot of other things too.

> I did some searching and came into discussion and there found out that in case of an error thrown, D just forcibly unwinds the stack without running destructors or scope guards. Is that true?

No, not generally.

> Can I even catch that Error?

Yes.

On Tue, 16 Feb 2016 17:35:02 +0000, Adam D. Ruppe wrote:

> On Tuesday, 16 February 2016 at 17:15:17 UTC, Jardík wrote:
>> But if I couldn't use GC and do all allocations and deallocations manually, I wouldn't even be able to use exceptions and there would also no longer be much reason to write it in D.
> 
> You can use exceptions without the GC and D offers a lot of other things too.

Specifically using http://dpldocs.info/search/search?searchTerm=emplace to create an exception object in manually allocated memory.

On Wednesday, 17 February 2016 at 00:45:35 UTC, Chris Wright wrote:
> http://dpldocs.info/search/search?searchTerm=emplace to create an exception object in manually allocated memory.

Aye, this overload: http://dpldocs.info/experimental-docs/std.conv.emplace.3.html

though the example there is awful, wtf is it even trying to show?


But anyway, you can also throw a static object. That's actually what outOfMemoryError does <http://dpldocs.info/experimental-docs/core.exception.onOutOfMemoryError.html> - it throws a statically allocated object.

On Tuesday, 16 February 2016 at 17:15:17 UTC, Jardík wrote:
> But if I couldn't use GC and do all allocations and deallocations manually, I wouldn't even be able to use exceptions and there would also no longer be much reason to write it in D. I did some searching and came into discussion and there found out that in case of an error thrown, D just forcibly unwinds the stack without running destructors or scope guards. Is that true? Can I even catch that Error?

Such errors are static errors, they aren't allocated on the stack, a 128 bytes buffer is shared accross threads to keep them.

On Wednesday, 17 February 2016 at 02:23:34 UTC, cym13 wrote:
> Such errors are static errors, they aren't allocated on the stack, a 128 bytes buffer is shared accross threads to keep them.

Sorry, of course I meant they *are* allocated on the stack.

On Tuesday, 16 February 2016 at 17:15:17 UTC, Jardík wrote:
> But if I couldn't use GC and do all allocations and deallocations manually, I wouldn't even be able to use exceptions and there would also no longer be much reason to write it in D.

I'd say if you're going to grow GC heap so big it doesn't fit in memory it's a bad idea in the first place, since each GC cycle will take a lot of time, like, a lot. It might also leak. In a 32-bit process it will leak almost for sure.
So keep GC heap for small litter (including exceptions) and use other allocators for large pieces of data. This way you may get best of what D offers without long-GC-pause or out-of-memory-termination pains.