Per thread heap, GC, etc. (page 3)

On Friday, 14 May 2021 at 16:59:58 UTC, H. S. Teoh wrote: > IMO that impression is misleading, because those who are happy with the GC are silent and you don't hear from them, and the ones complaining about it are the vocal minority. Yes that could well explain a good proportion of it. But then I do find the argument valid for many application scenarios. And I would probably think less of it if I hadn't watched many of the Dconf and other sessions, where the topic of non-GC memory safety seems very dominant. There is this constant "the grass is greener over there" vibe coming across, with nods to Rust et al. All the proposals I encountered so far (@life etc.) always want to ditch the GC entirely (as a global application choice) and that's something that I think will be very damaging to D's power and ecosystem. It will effectively ban all the existing D code base from these applications and make the life so much harder for those that want to support both worlds. I guess there will be two stdlibs and two of everything, or if unified it will be crippled. The proposal I made here might fix this. If it works, it is the best of both worlds, combined. _Mark

May 14, 2021

Re: Per thread heap, GC, etc.

Posted by Markk
in reply to H. S. Teoh

Permalink

Markk

Posted in reply to H. S. Teoh

Permalink

On Friday, 14 May 2021 at 16:11:26 UTC, H. S. Teoh wrote:

However, there's a big caveat: sharing data between threads would be essentially extremely broken. Today, immutable can be safely shared across threads, because well, it's immutable. But once allocations are bound to a thread, this sharing would be impossible without major problems.

No! I did not say this explicitly but of course immutable and shared remain the same. I was talking about heap memory.

> >

I.e. all allocations would need to be per thread, and it would be illegal to reference memory of one thread's heap, static memory, or stack from another thread's memory.
[...]

Yeah, this would be a major bugbear for implementing it in D.

Compared to what for instance @life has to analyze, it is super easy, I think.

_Mark

On Friday, 14 May 2021 at 16:59:58 UTC, H. S. Teoh wrote: > Nobody is forcing you to do anything. If you don't like D because of the GC, there's plenty of alternatives, like Rust, that people here seem to love talking about. Nobody's twisting your arm that you must use D, and nobody's holding a gun to your head that you must use the GC. Everybody understands that, but you also have to look at where computing is heading and where people are moving. The trend now is that many people create new languages (thanks to LLVM) for system-like programming. As a result you get many small eco system that cannot sustain themselves well. The big winners... C++/Rust and other languages that have momentum.

On Friday, 14 May 2021 at 17:13:00 UTC, IGotD- wrote:

On Friday, 14 May 2021 at 17:02:00 UTC, Markk wrote:

If for example C++ calls a D function, the D function does something temporary with arrays then those arrays will not be cleaned up if the array memory is thread local.

First of all, if the D function lives in the C++ thread (i.e. normal callback) then it inherits the memory management of the C++ thread (e.g. non-GC) and would have to behave accordingly. The situation is much better than today, where the C++ thread punches into the D memory managed world, and it is solely the developers' responsibility to make sure not to return GC'd memory back to the C++ thread. The language guarantees (I described in the initial post) would make sure that nothing illegal can leak back into C++ by disallowing memory references from other (GC'd) threads.

If however the C++ call wanted to pass memory to/from other D threads, It could do so via message passing. Everything is properly managed and accounted for, by the thread separation.

_Mark

On Friday, 14 May 2021 at 16:59:58 UTC, H. S. Teoh wrote: > On Fri, May 14, 2021 at 04:25:47PM +0000, russhy via Digitalmars-d wrote: >> On Friday, 14 May 2021 at 15:30:46 UTC, Adam D. Ruppe wrote: >> > On Friday, 14 May 2021 at 15:23:13 UTC, Markk wrote: >> > > But look at even this forum. It seems to be one of the biggest no-gos for D. > > IMO that impression is misleading, because those who are happy with the GC are silent and you don't hear from them, and the ones complaining about it are the vocal minority. > > >> > There's two types of programmer: the ones busy doing actual productive work and the ones with the spare time to complain about GC on the forum. >> >> nobody complain about the GC > > Oh the irony. > > >> people complain about the fact everything is modeled around the idea of a poors man GC, implemented and served to everyone by force > > Nobody is forcing you to do anything. If you don't like D because of the GC, there's plenty of alternatives, like Rust, that people here seem to love talking about. Nobody's twisting your arm that you must use D, and nobody's holding a gun to your head that you must use the GC. > > :-D > > > T because of phobos and its people i should stop write D? i like D with core.stdc, i don't touch anything from std.

On Friday, 14 May 2021 at 23:13:38 UTC, russhy wrote: > because of phobos and its people i should stop write D? i like D with core.stdc, i don't touch anything from std. No, please not. But changing stdlib to support other forms of GC may lead to breakage of existing functionality which require to rewrite existing code using GC. >people complain about the fact everything is modeled around the idea of a poors man GC Could you elaborate more about the poor man GC? I think this talked is concerned a bit around that. What are your ideas to make it non poor man?

Forums