On 9/20/14, 1:46 AM, Uranuz wrote:
> Also it's interesting waht is the correspondence between memory
> management, memory model and allocators? I know that std.allocator is in
> development. I guess that it should be considered in complex.

1. Memory management: when are calls to allocation and deallocation primitives made?

2. Allocators: what are the allocation and deallocation primitives, and how are they implemented?

3. Memory model: how is memory effected by programs? (of interest for compiler implementers and thread safety)

There is occasional confusion among the three. I myself was in the woods for a while thinking that allocators should do memory management.


Andrei

On 9/20/14, 2:05 AM, ponce wrote:
> On Friday, 19 September 2014 at 15:32:38 UTC, Andrei Alexandrescu wrote:
>> Please chime in with thoughts.
>
> Coudln't we throw value types instead? (like in C++)

My knee-jerk reaction is we shouldn't. If considered, that would need to be well argued. We've derived good benefits from using polymorphic exceptions. -- Andrei

On 9/20/14, 5:17 AM, bearophile wrote:
> Andrei Alexandrescu:
>
>>> Are you suggesting we implement ARC?
>>
>> Yes. -- Andrei
>
> I think it's better first to design & implement a first version of
> memory ownership management, and then later add a reference counting
> scheme.

That's not quite informative. -- Andrei

On 9/20/14, 7:31 AM, Adam D. Ruppe wrote:
> How often do you store an exception reference anyway that escapes a
> catch block? I think all this talk is overkill to solve a non-problem in
> 99% of practice.
>
>
> Correct me if I'm wrong, but aren't *all* exceptions in a particular
> thread generally unreferenced at the end of a catch() block, unless the
> programmer explicitly escaped that reference?
>
> If so, we don't need refcounting! Here's my solution:
[snip]

Thanks. I personally favor RC based on malloc to this. It'll be safer and simpler to use. -- Andrei

On 9/20/14, 7:33 AM, Dicebot wrote:
> On Saturday, 20 September 2014 at 14:31:36 UTC, Adam D. Ruppe wrote:
>> How often do you store an exception reference anyway that escapes a
>> catch block? I think all this talk is overkill to solve a non-problem
>> in 99% of practice.
>
> Pretty much any time you do fibers + async I/O : to emulate blocking API
> one needs to catch and store exceptions from I/O routines so that later
> those can be re-thrown from resumed fiber context.

Interesting. Are those stored as Object or Throwable/Exception? -- Andrei

Am 20.09.2014 17:08, schrieb Jacob Carlborg:
> On 2014-09-20 16:33, Paulo Pinto wrote:
>
>> It requires compiler support, though.
>
> The first thing I asked in this thread was "Are you suggesting we
> implement ARC?" and the answer was "Yes" [1]. So it looks like Andrei
> already wants to implement ARC. My definition of ARC is that the
> compiler inserts the calls to retain/release (or whatever you call them).
>
> [1]
> http://forum.dlang.org/thread/lvhiam$1pno$1@digitalmars.com#post-lvi0ve:2429il:241:40digitalmars.com
>
>

I would say ARC == RC. I never saw a distinction in literature between both, before Apple used the term.

With all these discussions I have been digging into old papers, and due to that I am starting to change my opinion.

As it seems, RC with GC for cycle collection was more common than I thought of.

In the end, what matters is having automatic memory management, be it via GC, RC or compiler dataflow analysis.

From an outsider point of view, I just think that whatever the final outcome, it should be in a way that avoids the runtime episode from repeating itself.

--
Paulo

On 9/20/14, 8:05 AM, Adam D. Ruppe wrote:
> Nevertheless though, I still think the lifetime management there is
> simple enough for the user-programmer that freeing it manually isn't a
> big hassle and not worth making major changes to the language over.

The language will change in major ways, and this is the warmup before that. -- Andrei

On 9/20/14, 8:08 AM, Jacob Carlborg wrote:
> On 2014-09-20 16:33, Paulo Pinto wrote:
>
>> It requires compiler support, though.
>
> The first thing I asked in this thread was "Are you suggesting we
> implement ARC?" and the answer was "Yes" [1]. So it looks like Andrei
> already wants to implement ARC. My definition of ARC is that the
> compiler inserts the calls to retain/release (or whatever you call them).
>
> [1]
> http://forum.dlang.org/thread/lvhiam$1pno$1@digitalmars.com#post-lvi0ve:2429il:241:40digitalmars.com

Please don't take me in a court of law. But yes, I am talking about the compiler inserting calls to increment and decrement reference counts. -- Andrei

On Saturday, 20 September 2014 at 14:31:36 UTC, Adam D. Ruppe wrote:
> How often do you store an exception reference anyway that escapes a catch block? I think all this talk is overkill to solve a non-problem in 99% of practice.
>
>
> Correct me if I'm wrong, but aren't *all* exceptions in a particular thread generally unreferenced at the end of a catch() block, unless the programmer explicitly escaped that reference?
>
> If so, we don't need refcounting! Here's my solution:

I proposed something very similar in this thread[1], except I proposed a solution that is fully backwards-compatible except the rare case when exceptions are escaped, in which case it causes a compile-time error. Might be worth a look.

I don't think it's acceptable that code using Phobos is suddenly leaking until they add the new manual cleanup call.

[1] http://forum.dlang.org/post/stlslhjndgugecvmbowd@forum.dlang.org

On 9/20/14, 9:31 AM, Adam D. Ruppe wrote:
> On Saturday, 20 September 2014 at 16:15:45 UTC, Andrei Alexandrescu wrote:
>> We need to explore that. A possibility is to support coexistence and
>> then have the option to use a tool statically pinpoint the uses of GC.
>> -- Andrei
>
> What, *exactly*, does "uses of GC" mean? In other words, what
> specifically makes GC.malloc evil that must be avoided at any cost while
> C malloc (+ GC.addRange most likely) is an acceptable replacement?
>
> A few things that come to mind are:
>
> 1) Obviously, GC.malloc can trigger a collection. But this can be easily
> disabled.
>
> 2) The GC lock? I don't know how malloc handles this though.
>
> 3) Is GC.free substantially different than C's free?
>
> 4) Programmers don't typically explicitly free GC memory... but we could.
>
> 5) Bookkeeping overhead? I know malloc has some too though, is this
> really a dealbreaker?
>
> 6) Public relations.
>
> ....that's all I can think of. What am I missing? Which one of these is
> actually causing the problem that we're supposed to be fixing here?

The only problem is that GC.malloc doesn't need to be paired by a call to GC.free, whereas malloc must.

Andrei