www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Memory Management in 2021?

reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
Is there a rough plan for where D is heading with memory 
management in 2021?

Just roughly?

I also wonder if it would be possible to use refcounting (or ARC) 
for everything except class objects. Then add write barriers for 
pointers to class objects only and leave those garbage collected 
with a lower latency incremental mark/sweep collector. That 
should work out mostly ok for performance?
Jan 01
parent reply IGotD- <nise nise.com> writes:
On Friday, 1 January 2021 at 17:07:17 UTC, Ola Fosheim Grøstad 
wrote:
 Is there a rough plan for where D is heading with memory 
 management in 2021?

 Just roughly?

 I also wonder if it would be possible to use refcounting (or 
 ARC) for everything except class objects. Then add write 
 barriers for pointers to class objects only and leave those 
 garbage collected with a lower latency incremental mark/sweep 
 collector. That should work out mostly ok for performance?
We absolutely need a roadmap and a vision where D needs to go when it comes to memory management. Many of us expected this to clear up with Walter's presentation at Dconf 2020 but it was more basic explaining the concepts with the borrow/checker and was not something that revealed any information about any direction of the memory management in D. This is a subject with a lot of opinions but the D project has to do through with this despite it demands a lot of work and discussions.
Jan 01
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Friday, 1 January 2021 at 18:22:31 UTC, IGotD- wrote:
 We absolutely need a roadmap and a vision where D needs to go 
 when it comes to memory management. Many of us expected this to 
 clear up with Walter's presentation at Dconf 2020 but it was 
 more basic explaining the concepts with the borrow/checker and 
 was not something that revealed any information about any 
 direction of the memory management in D.

 This is a subject with a lot of opinions but the D project has 
 to do through with this despite it demands a lot of work and 
 discussions.
Personally I would like to see some clarity on the status of, and future plans for, std.experimental.allocator. What needs to happen for it to "graduate" into std proper? Who (if anyone) is working on making that happen?
Jan 01
prev sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Friday, 1 January 2021 at 18:22:31 UTC, IGotD- wrote:
 On Friday, 1 January 2021 at 17:07:17 UTC, Ola Fosheim Grøstad 
 wrote:
 Is there a rough plan for where D is heading with memory 
 management in 2021?

 Just roughly?

 I also wonder if it would be possible to use refcounting (or 
 ARC) for everything except class objects. Then add write 
 barriers for pointers to class objects only and leave those 
 garbage collected with a lower latency incremental mark/sweep 
 collector. That should work out mostly ok for performance?
We absolutely need a roadmap and a vision where D needs to go when it comes to memory management. Many of us expected this to clear up with Walter's presentation at Dconf 2020 but it was more basic explaining the concepts with the borrow/checker and was not something that revealed any information about any direction of the memory management in D. This is a subject with a lot of opinions but the D project has to do through with this despite it demands a lot of work and discussions.
I mentioned having a working group on memory safety previously. If I all goes to plan I am supposed to be Mike's glamorous assistant soon-ish(?) (thank you symmetry), and I would be very interesting in running something along those lines. Memory safety is a bit of Pandora's box, though, because it means getting move semantics right not only directly but also in what to do with the moved-from object (for example). We have the option to not be C++ on this matter, and we should probably take it. What live does is where we should be aiming for - RAII alone isn't good enough any more.
Jan 01
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 2 January 2021 at 00:03:11 UTC, Max Haughton wrote:
 I mentioned having a working group on memory safety previously.
That would be great. Maybe use this forum: https://forum.dlang.org/group/study Then people could follow the various ideas?
Jan 01
prev sibling parent RSY <rsy_881 gmail.com> writes:
On Saturday, 2 January 2021 at 00:03:11 UTC, Max Haughton wrote:
 On Friday, 1 January 2021 at 18:22:31 UTC, IGotD- wrote:
 On Friday, 1 January 2021 at 17:07:17 UTC, Ola Fosheim Grøstad 
 wrote:
 Is there a rough plan for where D is heading with memory 
 management in 2021?

 Just roughly?

 I also wonder if it would be possible to use refcounting (or 
 ARC) for everything except class objects. Then add write 
 barriers for pointers to class objects only and leave those 
 garbage collected with a lower latency incremental mark/sweep 
 collector. That should work out mostly ok for performance?
We absolutely need a roadmap and a vision where D needs to go when it comes to memory management. Many of us expected this to clear up with Walter's presentation at Dconf 2020 but it was more basic explaining the concepts with the borrow/checker and was not something that revealed any information about any direction of the memory management in D. This is a subject with a lot of opinions but the D project has to do through with this despite it demands a lot of work and discussions.
I mentioned having a working group on memory safety previously. If I all goes to plan I am supposed to be Mike's glamorous assistant soon-ish(?) (thank you symmetry), and I would be very interesting in running something along those lines. Memory safety is a bit of Pandora's box, though, because it means getting move semantics right not only directly but also in what to do with the moved-from object (for example). We have the option to not be C++ on this matter, and we should probably take it. What live does is where we should be aiming for - RAII alone isn't good enough any more.
i'm not sure yet another will solve anything I personally avoid them because they clutter the code, just like comments, people tend to abuse them..
Jan 01