November 17
> during which the whole world is stopped,

create a new thread and don't register it with the gc. it wont be stopped.
November 17
On Wednesday, 17 November 2021 at 18:09:56 UTC, Zoadian wrote:
> On Wednesday, 17 November 2021 at 02:32:21 UTC, H. S. Teoh wrote:
>> On Wed, Nov 17, 2021 at 01:57:23AM +0000, zjh via Digitalmars-d wrote:
>>> [...]
>>
>> Why bend over backwards to please the GC-phobic crowd?  They've already made up their minds, there's no convincing them.
>>
>> [...]
>
> I 100% agree with this. There are more important things that need improvement. GC and no-GC work well enough in D (Exceptions are the only thing that needs a bit of extra work with @nogc).

Yes, we need to focus on the bigger picture
November 17

Thanks Steve.

On Wednesday, 17 November 2021 at 17:19:31 UTC, Steven Schveighoffer wrote:

>

I have to say, the second I see "How to X with DLL" in this forum, I mark as read and continue. D has a horrible story on DLLs, and it's been like that for as long as I can remember. If there is some infrastructure project that needs attention, it's DLLs. You are right that betterC and importC are useless if using D from C is nigh impossible or so difficult even the experts can't tell you the answer.

HOWEVER -- there is no excuse for the runtime hanging when a possible error is detected from a system call. Your linked discussion was not resolved how it should have been. Either the runtime should deal with that result properly, or it should crash the application completely. Not properly handling system call errors deep in the runtime is not acceptable.

If no bug has been filed on this, please do.

After the experience we've ended up with a workaround that passes requests from C# threads to single thread managed by D's runtime. It works kind off. It's not pretty or most effective, but at least it doesn't crash. Only on DLL unload it has problems sometimes but that is only on program exit anyway so not a big deal for us.

But if I'd do something differently now, I'd end up using betterC only library for this case and avoided runtime completely.

>

I believe the GC can be tuned to reduce this, as long as you haven't at one point needed that much memory at once.

Yes, we have found some settings that makes it better (highest impact has progressive growing of the allocated pages set to 1).

>

However, it is worth noting that GC (in any language) generally does require more memory than manual allocation or reference counting. D does not have the ability to use a moving GC, because of the type system, which makes compacting GC impossible unfortunately.

Yes it's expected but when I've seen the reported numbers of what is allocated and how much of that is actually free I had my doubts that it is caused only by fragemtation.
But there are no official tools, nor druntime facility to make some GC memory map of what is actually there and where so it's pretty hard to tell and diagnose this.
I've ended up using linux debuging tools to at least see when it allocates next page from what stack, but too many allocations rendered it impossible to process (but at least lead us to the dpq2 allocation problem). After that it became much better so we've decided to move it back to backlog as it would require much more time to move further).

>

Oof, the dpq2 library should fix that (probably malloc/free the temporary C string). Have you filed a bug on that?

Nope, just internal patch, but I've fixed that: https://github.com/denizzzka/dpq2/issues/161

>

If I can separate the use cases here, using D as a main application, on a normal modern server/desktop, I have found using the GC to be a non-issue.

There are problems clearly with:

  • using D with GC as a plugin
  • using GC in a memory/resource constrained environment

Does that sound fair?

Yes, there are uses where GC is not much of a problem and when is, it can be worked around where it makes sense.

>

This doesn't make sense, as I believe async/await in languages enables the compiler to rewrite your functions into a state machine. How it stores the state might not need GC usage, because the compiler is in control of the state creation and the state usage.

I wouldn't expect it to need more GC abilities than scope(exit) does.

I might be wrong, but I guess there would be more to it as a scheduler that would control where the work is actually done controlling some Future/Promise facilities. And when it comes to Thread/Fiber synchronization, then..

But I'm not an expert in this field and as you, I'm more used to seemingly blocking API that is possible in vibe-d/mecca.

>

If you refer to UFCS and/or templates, I'm not sure how solvable a problem this is.

No this is more about that it just stops working completely and needs the restart. I can understand that not all code completion is possible, but in this case what has worked just stops working. Not sure why or where (might be a project organization with many subprojects in a relative paths, etc.). But as I said, I'm used to it. This is more about newcomers that might be scared away ;-) For debugging I use printf/gdb and I can live with that.

>

Having the other options is a nice possibility, but I would be very much against removing the GC, or refactoring everything so I have to think about non-GC options.

We're on the same page here. I'd also like the best of both worlds ;-)
Removing betterC or forcing GC on user would be a show stopper for me too.

>

Such is life. If you want an ecosystem built around a certain paradigm or low level design choice, you have to either create it or get others to join you in that paradigm.

D does give you the opportunity to do that, it certainly does take a lot of critical mass to do that.

Yes, unfortunately I haven't found any other language that I would like more. So even with its quirks, D is great but definitely deserves to be better.

November 17

On Wednesday, 17 November 2021 at 18:47:35 UTC, Imperatorn wrote:

>

On Wednesday, 17 November 2021 at 18:09:56 UTC, Zoadian wrote:

>

I 100% agree with this. There are more important things that need improvement. GC and no-GC work well enough in D (Exceptions are the only thing that needs a bit of extra work with @nogc).

Yes, we need to focus on the bigger picture

Well, the bigger picture is that D needs solid compiler-backed memory management and a solid memory model, including adjustments to shared.

What can be more important than that for a system level programming language?

Continuing with inventing homegrown ad-hoc solutions is basically free advertising for competing languages that has put in the work to get something consistent out-of-the-box.

I don't know Rust much and have absolutely no preference for it, but if I had to write a WASM module for a commercial project I probably would have given Rust a shot. As it looks like it might be the cheapest manageable option.

And NO, I don't want to run a GC in WASM.

November 17

On 11/17/21 2:07 PM, tchaloupka wrote:

>

Yes it's expected but when I've seen the reported numbers of what is allocated and how much of that is actually free I had my doubts that it is caused only by fragemtation.

I believe there is a minimum pool allocated, but I don't think it's in that range (250MB).

Some documentation on how the performance of the GC is expected would be nice to have on the web site.

-Steve

November 17

On Tuesday, 16 November 2021 at 18:17:29 UTC, Rumbu wrote:

>

At least from my point of view, it seems that recently D made a shift from a general purpose language to a C successor,

I mean, it kind of always was, which is even indicated in the name.

>

hence the last efforts to improve betterC and C interop, neglecting other areas of the language.

By other areas I mean half baked language built-ins or oop support which failed to evolve at least to keep the pace with the languages from where D took inspiration initially (e.g. Java and its successors).

Where would you say D has failed to evolve in terms of OOP?

>

Now, without a gc, more than half of the language risks to become unusable and that's why I ask myself how do you see the future of the memory management in D?

The GC isn't going anywhere. It's the easiest way to write memory-safe code other than leaking everything.

November 17

On Wednesday, 17 November 2021 at 21:46:45 UTC, Atila Neves wrote:

>

The GC isn't going anywhere. It's the easiest way to write memory-safe code other than leaking everything.

What is the plan for destructors?

Objects with destructors should not be allocated on the GC-heap. Will this become a type error that is caught at compile time?

November 17
On Wednesday, 17 November 2021 at 18:47:35 UTC, Imperatorn wrote:
> On Wednesday, 17 November 2021 at 18:09:56 UTC, Zoadian wrote:
>> On Wednesday, 17 November 2021 at 02:32:21 UTC, H. S. Teoh wrote:
>>> On Wed, Nov 17, 2021 at 01:57:23AM +0000, zjh via Digitalmars-d wrote:
>>>> [...]
>>>
>>> Why bend over backwards to please the GC-phobic crowd?  They've already made up their minds, there's no convincing them.
>>>
>>> [...]
>>
>> I 100% agree with this. There are more important things that need improvement. GC and no-GC work well enough in D (Exceptions are the only thing that needs a bit of extra work with @nogc).
>
> Yes, we need to focus on the bigger picture

Agreed.  Trying to please everybody is a losing battle.  If the GC is so offensive to you, why are you here?  There are other languages.

I'm using D to build a chess variant engine where there are recursive functions that call each other a million times a second.  I absolutely, positively cannot have any GC happening there!  No problem.  I pre-allocate what I need and I can further add @nogc to be certain.  (Which helped me because there was a place where I was doing a closure that could allocate and I didn't realize it.)

D is great at letting you go the direction you want.  The hysterical no-gc crowd should find another language.  That being said, reducing GC usage in phobos is a worth goal...
November 17

On Wednesday, 17 November 2021 at 22:36:51 UTC, Greg Strong wrote:

>

I'm using D to build a chess variant engine where there are recursive functions that call each other a million times a second.

Out of curiosity, why did you pick D for this task? Sounds like it is well suited for a high level language with high level optimization capabilities.

>

D is great at letting you go the direction you want. The hysterical no-gc crowd should find another language. That being said, reducing GC usage in phobos is a worth goal...

The hysterical no-gc crowd already found another language.

The low latency gc crowd also found another language.

A high latency gc-language is not something anyone actively looks for. That has to be fixed to fix the manpower-issue.

November 17

On 11/17/21 4:59 PM, Ola Fosheim Grøstad wrote:

>

On Wednesday, 17 November 2021 at 21:46:45 UTC, Atila Neves wrote:

>

The GC isn't going anywhere. It's the easiest way to write memory-safe code other than leaking everything.

What is the plan for destructors?

Objects with destructors should not be allocated on the GC-heap. Will this become a type error that is caught at compile time?

Nothing wrong with it. It works correctly if you use it correctly.

-Steve

1 2 3 4 5 6 7 8 9 10 11 12 13 14