Am Thu, 6 Feb 2014 20:00:50 +0100
schrieb Johannes Pfau <nospam@example.com>:

> Am Thu, 06 Feb 2014 18:52:20 +0000
> schrieb "fra" <a@b.it>:
> 
> > On Thursday, 6 February 2014 at 18:20:56 UTC, Andrei Alexandrescu wrote:
> > >> One interesting point is that module that were written with
> > >> avoiding
> > >> allocations in mind usually still allocate when throwing
> > >> exceptions.
> > >
> > > Good point, we need to address that as well.
> > >
> > >
> > > Andrei
> > 
> > Hey, wait a second. How do you throw without allocating?
> > 
> 
> You can store the exception as a global and that's done for the OutOfMemoryError IIRC, but what I meant was 'allocate with the GC'.

Oh and in other languages you can throw by value but I think that wouldn't work in D because of exception chaining.

On 6 February 2014 18:05, Johannes Pfau <nospam@example.com> wrote:
> Am Thu, 06 Feb 2014 16:32:08 +0000
> schrieb "Dicebot" <public@dicebot.lv>:
>
>> On Thursday, 6 February 2014 at 16:28:25 UTC, Andrei Alexandrescu wrote:
>> > Would anyone be willing to take on the ingrate task of creating a comprehensive list with all Phobos functions (and more generally artifacts) that allocate memory? That would help a lot with focusing the discussion.
>> >
>> > Andrei
>>
>> Merging https://github.com/D-Programming-Language/dmd/pull/1886 and running phobos unit tests should make it relatively simple, at least for a first pass.
>
> That's only for implicit allocations though. And please, don't merge yet, it'll get another rewrite this weekend ;-)
>
> One interesting point is that module that were written with avoiding allocations in mind usually still allocate when throwing exceptions.
>
> Here's some example output for std.uuid/digest/path/range/algorithm/curl: http://dpaste.dzfl.pl/96d3725b06e2

That message will look much better with vcolumns.  ;)

Albeit, it also depends on moving fprint(global.stdmsg, ...)  =>  message(...)

http://dpaste.dzfl.pl/5b1961918ed6

On 6 February 2014 18:52, fra <a@b.it> wrote:
> On Thursday, 6 February 2014 at 18:20:56 UTC, Andrei Alexandrescu wrote:
>>>
>>> One interesting point is that module that were written with avoiding allocations in mind usually still allocate when throwing exceptions.
>>
>>
>> Good point, we need to address that as well.
>>
>>
>> Andrei
>
>
> Hey, wait a second. How do you throw without allocating?
>

You can't. :o)

On Thursday, 6 February 2014 at 19:01:33 UTC, Johannes Pfau wrote:
> You can store the exception as a global and that's done for the
> OutOfMemoryError IIRC.

Hmm.. is that even safe? I mean in some case of exception chaining the same object could be overwritten before being thrown again, thereby losing the original exception state. Thinking out loud here..

On Thursday, 6 February 2014 at 19:05:49 UTC, Andrej Mitrovic wrote:
> On Thursday, 6 February 2014 at 19:01:33 UTC, Johannes Pfau wrote:
>> You can store the exception as a global and that's done for the
>> OutOfMemoryError IIRC.
>
> Hmm.. is that even safe? I mean in some case of exception chaining the same object could be overwritten before being thrown again, thereby losing the original exception state. Thinking out loud here..

You could use a circular buffer with appropriate length.

On Thursday, 6 February 2014 at 18:20:56 UTC, Andrei Alexandrescu wrote:
> On 2/6/14, 10:05 AM, Johannes Pfau wrote:
>> Am Thu, 06 Feb 2014 16:32:08 +0000
>> schrieb "Dicebot" <public@dicebot.lv>:
>>
>>> On Thursday, 6 February 2014 at 16:28:25 UTC, Andrei Alexandrescu
>>> wrote:
>>>> Would anyone be willing to take on the ingrate task of creating
>>>> a comprehensive list with all Phobos functions (and more
>>>> generally artifacts) that allocate memory? That would help a
>>>> lot with focusing the discussion.
>>>>
>>>> Andrei
>>>
>>> Merging https://github.com/D-Programming-Language/dmd/pull/1886
>>> and running phobos unit tests should make it relatively simple,
>>> at least for a first pass.
>>
>> That's only for implicit allocations though. And please, don't merge
>> yet, it'll get another rewrite this weekend ;-)
>
> Please close if you plan to rewrite.
>
>> One interesting point is that module that were written with avoiding
>> allocations in mind usually still allocate when throwing exceptions.
>
> Good point, we need to address that as well.
>

I'd think fixing that is probably above and beyond what is required to satisfy most people. If you are throwing so many exceptions that GC pauses are a problem you've got more serious problems than the GC.

nothrow doesn't concern itself with Error exceptions, I think nogc should just ignore exceptions generally.

>
> Andrei

On Thursday, 6 February 2014 at 18:52:21 UTC, fra wrote:
> Hey, wait a second. How do you throw without allocating?

I think exceptions should be ok. You optimize the typical path, and exceptions are (by definition) an exceptional path. If they are also unacceptable, you could restrict yourself to nothrow functions. (Which can still throw Errors... but meh they are even *more* exceptional)

On 6 February 2014 19:03, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 6 February 2014 18:05, Johannes Pfau <nospam@example.com> wrote:
>> Am Thu, 06 Feb 2014 16:32:08 +0000
>> schrieb "Dicebot" <public@dicebot.lv>:
>>
>>> On Thursday, 6 February 2014 at 16:28:25 UTC, Andrei Alexandrescu wrote:
>>> > Would anyone be willing to take on the ingrate task of creating a comprehensive list with all Phobos functions (and more generally artifacts) that allocate memory? That would help a lot with focusing the discussion.
>>> >
>>> > Andrei
>>>
>>> Merging https://github.com/D-Programming-Language/dmd/pull/1886 and running phobos unit tests should make it relatively simple, at least for a first pass.
>>
>> That's only for implicit allocations though. And please, don't merge yet, it'll get another rewrite this weekend ;-)
>>
>> One interesting point is that module that were written with avoiding allocations in mind usually still allocate when throwing exceptions.
>>
>> Here's some example output for std.uuid/digest/path/range/algorithm/curl: http://dpaste.dzfl.pl/96d3725b06e2
>
> That message will look much better with vcolumns.  ;)
>
> Albeit, it also depends on moving fprint(global.stdmsg, ...)  =>  message(...)
>
> http://dpaste.dzfl.pl/5b1961918ed6

Saying that, it seems it doesn't show the column number correctly.

http://dpaste.dzfl.pl/31c8800e223a

06-Feb-2014 21:21, Andrej Mitrovic пишет:
> On 2/6/14, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>> On 2/6/14, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>>> https://raw.github.com/AndrejMitrovic/phobos_allocations/master/phobos_allocations.txt
>>
>> Ah just realized there are duplicates in the report. I guess -vgc is
>> emitting dupes.
>
> Updated to remove duplicate reports.
>

Needs to somehow cut down CTFE-only stuff.
E.g. std.regex alocates a lot at CTFE (and in debug sections), it's a prominent example of CTFE but there is a _lot_ more in the same theme.

-- 
Dmitry Olshansky

On Thu, Feb 06, 2014 at 11:01:18AM -0800, Andrei Alexandrescu wrote:
> On 2/6/14, 10:52 AM, fra wrote:
> >On Thursday, 6 February 2014 at 18:20:56 UTC, Andrei Alexandrescu wrote:
> >>>One interesting point is that module that were written with avoiding allocations in mind usually still allocate when throwing exceptions.
> >>
> >>Good point, we need to address that as well.
> >>
> >>
> >>Andrei
> >
> >Hey, wait a second. How do you throw without allocating?
> 
> I don't know yet. That's what the "addressing the problem" will take care of! :o)
[...]

You can just pre-declare the Exception as a global variable and then throw that. Well, OK, it's cheating because you still have to allocate it then, but the point is that you get to control how it gets allocated at the top-level rather than having the 'new' buried deep down in the function call chain where you can't control whether the code uses 'new' or a custom allocator (it may not know about which allocator to use).

	Exception prealloc_exc;
	static this() {
		prealloc_exc = ... /* use whatever allocation method you want */
	}
	void main() {
		try {
			func();
		} catch(Exception e) {
			// you get prealloc_exc here
		}
	}
	void func() {
		if (error) {
			// init exception parameters
			prealloc_exc.msg = ...;
				/* presumably you preallocate the
				 * message string too, with the
				 * allocator of your choice */

			throw prealloc_exc; // N.B. no allocation
		}
	}


T

-- 
Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye