On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
> The new GC in Go 1.5 seems interesting. What they say about is certainly interesting.
>
> http://blog.golang.org/go15gc
>
> "To create a garbage collector for the next decade, we turned to an algorithm from decades ago. Go's new garbage collector is a concurrent, tri-color, mark-sweep collector, an idea first proposed by Dijkstra in 1978."

I sometimes wonder - and please forgive me my ignorance, because I'm not a GC expert at all - if it would be possible to create a system where the created objects know their own life spans and destroy themselves, once they are no longer used. Like the cells in our bodies.

On Monday, 21 September 2015 at 09:58:31 UTC, Chris wrote:
> I sometimes wonder - and please forgive me my ignorance, because I'm not a GC expert at all - if it would be possible to create a system where the created objects know their own life spans and destroy themselves, once they are no longer used. Like the cells in our bodies.

Yes, this is the system Rust uses, but the compiler has to prove the life spans at compile time. So how convenient that is, is limited to the capabilities of the prover and for how long you want to wait for the computation of the life times.

In essence you have to choose between a simple tracking system that is a bit annoying and solving NP-complete problems (which may work out fine in many cases, but not in all possible configurations).

There are many ways to improve on this based on what tradeoffs you accept. Like you could segment the heap and prove that at a given point all the objects in the heap have to be dead, and just accept that you waste some memory up until that point.

Etc.

On Monday, 21 September 2015 at 10:18:17 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 21 September 2015 at 09:58:31 UTC, Chris wrote:
>> I sometimes wonder - and please forgive me my ignorance, because I'm not a GC expert at all - if it would be possible to create a system where the created objects know their own life spans and destroy themselves, once they are no longer used. Like the cells in our bodies.
>
> Yes, this is the system Rust uses, but the compiler has to prove the life spans at compile time. So how convenient that is, is limited to the capabilities of the prover and for how long you want to wait for the computation of the life times.

So I'm not completely nuts! Good to know. :) I wonder, if something like this is feasible in D.

On Monday, 21 September 2015 at 10:25:05 UTC, Chris wrote:
> So I'm not completely nuts! Good to know. :) I wonder, if something like this is feasible in D.

I am too. I'm toying with some ideas, but I think it would work mostly for shorter programs. Then again, I'm mostly interested in shorter programs...

On Monday, 21 September 2015 at 10:25:05 UTC, Chris wrote:
> On Monday, 21 September 2015 at 10:18:17 UTC, Ola Fosheim Grøstad wrote:
>> On Monday, 21 September 2015 at 09:58:31 UTC, Chris wrote:
>>> I sometimes wonder - and please forgive me my ignorance, because I'm not a GC expert at all - if it would be possible to create a system where the created objects know their own life spans and destroy themselves, once they are no longer used. Like the cells in our bodies.
>>
>> Yes, this is the system Rust uses, but the compiler has to prove the life spans at compile time. So how convenient that is, is limited to the capabilities of the prover and for how long you want to wait for the computation of the life times.
>
> So I'm not completely nuts! Good to know. :) I wonder, if something like this is feasible in D.

There's also a simple thing called smart pointers which do this with RAII, copy and move semantics. Smart pointers manage the lifetime of the object they point to automatically. You just need to make sure that you access the object only through the smart pointer, because if you get another reference (through other means) that the smart pointer doesn't know about, the smart pointer may free the object too early.

I prefer library-defined smart pointers than language magic, because you can easily modify them to fit your needs. What D needs is a way to enforce that the user can't get unmanaged references to the underlying object managed by the smart pointer.

The killer way to implement this in D is to NOT add complexity in the compiler (and to change the whole language to some imaginable perfect correct memory management system), but to add away for the library writers to write extensible CTFE checkers that enforce the smart pointer invariants at compile-time.

On 2015-09-19 17:56:21 +0000, thedeemon said:

> If we carefully use addRoot() and addRange() for data directly pointing to GC heap I think we don't need to let GC scan everything that can lead to this data. This is error-prone in general, of course.

Well, that's a different name for malloc & free...

I don't see any value in using a GC that needs addRoot / addRange, then I can do manual memory management as well.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

On Monday, 21 September 2015 at 11:01:27 UTC, ZombineDev wrote:
> I prefer library-defined smart pointers than language magic, because you can easily modify them to fit your needs. What D needs is a way to enforce that the user can't get unmanaged references to the underlying object managed by the smart pointer.

That's ok. I've done that in my own prototype library by having a "movingptr!T" returned by doing "move(someuniqueptr)" and "borrowptr!T" returned by "borrow(...)". But checking is limited to runtime asserts in destructors in debug builds.

It is ok as a runtime hack... but not a competitive solution.

> The killer way to implement this in D is to NOT add complexity in the compiler (and to change the whole language to some imaginable perfect correct memory management system), but to add away for the library writers to write extensible CTFE checkers that enforce the smart pointer invariants at compile-time.

That is most likely even more work than creating a language solution?

On Monday, 21 September 2015 at 12:04:11 UTC, Ola Fosheim Grøstad wrote:

>
> That is most likely even more work than creating a language solution?

What's the current state of D's GC. Will std.allocator improve things eventually?

On Monday, 21 September 2015 at 14:30:19 UTC, Chris wrote:
> What's the current state of D's GC. Will std.allocator improve things eventually?

I don't understand the point of std.allocator.

AFAIK the current GC has very limited compiler support. A smart compiler could move allocations to the stack by doing smart static analysis, cluster pointers that should be traced to the same cache lines etc.

Moving to library allocation just makes it even harder to write a smart compiler, for very little gain IMO (i.e. custom allocators will always be better).

On Monday, 21 September 2015 at 11:01:27 UTC, ZombineDev wrote:
>
> There's also a simple thing called smart pointers which do this with RAII, copy and move semantics. Smart pointers manage the lifetime of the object they point to automatically. You just need to make sure that you access the object only through the smart pointer, because if you get another reference (through other means) that the smart pointer doesn't know about, the smart pointer may free the object too early.

My understanding is that the key benefit of Rust's system is that compile time checks don't have the runtime costs of smart pointers.