www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Garbage Collector

reply Konstantin <soonts gmail.com> writes:
Started learning D. Like the language. However, found several 
people complaining about garbage collector’s reliability and 
performance. For me it’s a showstopper.

I don’t believe a community is capable of creating a good GC. 
It’s just too complex engineering task. It’s been a known problem 
for years, still no solution.

Since recently, Microsoft’s .NET framework and runtime are open 
source under MIT license. Here’s the main parts of their GC:  
https://github.com/dotnet/coreclr/tree/master/src/gc As you see, 
it’s in C++, and contains 10-20 times more code, then D’s GC. 
Theoretically, it should be cross-platform: there’re build 
instructions for Linux (including ARM), OSX, and BSD; but I 
haven’t tried building on those.

Has anyone thought about taking GC from .NET and reusing it in D?

That GC is very efficient for wide range of applications. I’ve 
been using .NET since 3.0 on desktops, servers, embedded and 
mobiles, never had issues with GC, it just works, and the 
performance is good.

I don‘t know architectural details of either GC.

I perfectly aware it might happen so they are completely 
incompatible, or very hard to port: because .NET’s System.Object 
vs. D’s Object differences; because D’s fibers or just very 
different threading model; because different CRT; many other 
reasons possible.

But if we’re lucky, this GC could lead to a great improvement for 
D ecosystem, not costing too much time. IMO that is something 
doable by a single person in a spare time.

Thoughts?
Jun 15 2016
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:
 Started learning D. Like the language. However, found several 
 people complaining about garbage collector’s reliability and 
 performance. For me it’s a showstopper.
Possible to disable.
 I don’t believe a community is capable of creating a good GC. 
 It’s just too complex engineering task. It’s been a known 
 problem for years, still no solution.
They've got a GSOC guy workin' on it now. I would hold off judgements until that effort is concluded.
 Has anyone thought about taking GC from .NET and reusing it in 
 D?
I don't think this would work, but I don't know enough to be able to explain why.
Jun 15 2016
parent Konstantin <soonts gmail.com> writes:
On Wednesday, 15 June 2016 at 13:27:47 UTC, jmh530 wrote:

 Possible to disable.
I don’t want to: for the last couple years I’ve been developing 50/50 C++/C#, and I admit I’m usually more productive using C#, one of the reasons of that is GC.
 They've got a GSOC guy workin' on it now. I would hold off 
 judgements until that effort is concluded.
OK let's see.
Jun 15 2016
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
I'm not sure how much you know about D but:

1. Somebody is working on improving D's GC as part of GSOC in the hopes 
of making it able to be precise (from memory not 100% sure).
2. Only a few language features forces you to use the GC.
3. For most uses you are not forced to use the GC in any form especially 
with the help of std.experimental.allocator.
4. Our GC is based upon the Boehm GC. Its old. Even the more recent 
versions would be far better then what we have (we forked a long time ago).
5. The requirements for our GC is quite intricate. I.e. you can't just 
pop in one that doesn't understand about our Thread Local Storage (TLS) 
and stuff.
6. As said by somebody else we can disable the GC so it won't go ahead 
and scan upon allocation (only time it does).
Jun 15 2016
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 16/06/2016 1:33 AM, rikki cattermole wrote:
 I'm not sure how much you know about D but:

 1. Somebody is working on improving D's GC as part of GSOC in the hopes
 of making it able to be precise (from memory not 100% sure).
 2. Only a few language features forces you to use the GC.
 3. For most uses you are not forced to use the GC in any form especially
 with the help of std.experimental.allocator.
 4. Our GC is based upon the Boehm GC. Its old. Even the more recent
 versions would be far better then what we have (we forked a long time ago).
 5. The requirements for our GC is quite intricate. I.e. you can't just
 pop in one that doesn't understand about our Thread Local Storage (TLS)
 and stuff.
 6. As said by somebody else we can disable the GC so it won't go ahead
 and scan upon allocation (only time it does).
I forgot to mention, good D code is not the same as a higher level language like Java. Here you don't have the automagick behavior of arrays. If you append it will have a high cost. All allocations have a large cost. Instead allocate in one large block which will of course be a whole lot faster then small tiny ones. So even if the GC is enabled, good D code won't cause too much slow down unless you decide to write heavy OOP code.
Jun 15 2016
parent reply Konstantin <soonts gmail.com> writes:
On Wednesday, 15 June 2016 at 13:40:11 UTC, rikki cattermole 
wrote:

 5. The requirements for our GC is quite intricate. I.e. you 
 can't just
 pop in one that doesn't understand about our Thread Local 
 Storage (TLS)
 and stuff.
D’s TLS that different from .NET's TLS? https://msdn.microsoft.com/en-us/library/system.threadstaticattribute(v=vs.110).aspx
 I forgot to mention, good D code is not the same as a higher 
 level language like Java.
 Here you don't have the automagick behavior of arrays. If you 
 append it will have a high cost. All allocations have a large 
 cost. Instead allocate in one large block which will of course 
 be a whole lot faster then small tiny ones.
You’re saying memory allocations in D are generally very expensive, but that’s not a problem, because it already functions as designed?
 So even if the GC is enabled, good D code won't cause too much 
 slow down unless you decide to write heavy OOP code.
I’ve been developing heavy OOP code in various languages (mostly C++, but also C# and Objective-C) for decades already. OOP works very well for me.
Jun 15 2016
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 16/06/2016 4:52 AM, Konstantin wrote:
 On Wednesday, 15 June 2016 at 13:40:11 UTC, rikki cattermole wrote:

 5. The requirements for our GC is quite intricate. I.e. you can't just
 pop in one that doesn't understand about our Thread Local Storage (TLS)
 and stuff.
D’s TLS that different from .NET's TLS? https://msdn.microsoft.com/en-us/library/system.threadstaticattribute(v=vs.110).aspx
Yes it most definitely is. We roll our own for platforms that do not support it. There is an abstraction in druntime specifically to handle this problem.
 I forgot to mention, good D code is not the same as a higher level
 language like Java.
 Here you don't have the automagick behavior of arrays. If you append
 it will have a high cost. All allocations have a large cost. Instead
 allocate in one large block which will of course be a whole lot faster
 then small tiny ones.
You’re saying memory allocations in D are generally very expensive, but that’s not a problem, because it already functions as designed?
No. Memory allocations are /always/ expensive. Higher level languages like Java have the benefit of using pools and optimizing for this usage pattern, D does and will never have this. Keep in mind an allocation = usage of malloc + write to returned pointer.
 So even if the GC is enabled, good D code won't cause too much slow
 down unless you decide to write heavy OOP code.
I’ve been developing heavy OOP code in various languages (mostly C++, but also C# and Objective-C) for decades already. OOP works very well for me.
Well if you really insist to have a String class don't be too surprised for some reason it doesn't have the same performance to say Java. Aka don't go around creating/destroying classes a huge amount unless you have rolled some form of memory management policy such as reserving memory for the GC to use. We have other tools where OOP normally would be used such as templates, structs, function pointers and delegates.
Jun 15 2016
parent reply Konstantin <soonts gmail.com> writes:
On Wednesday, 15 June 2016 at 17:02:11 UTC, rikki cattermole 
wrote:

 Higher level languages like Java have the benefit of using 
 pools and optimizing for this usage pattern, D does and will 
 never have this.
Why don't you want the same for D?
 Well if you really insist to have a String class don't be too 
 surprised for some reason it doesn't have the same performance 
 to say Java.
Some areas, like compiling, or producing HTML/XML/JSON documents, manipulate strings a lot. Other areas, like GUI editors for sufficiently complex documents, or level editors for videogame, need to efficiently manipulate huge trees of assorted small objects, not necessarily strings.
 Aka don't go around creating/destroying classes a huge amount 
 unless you have rolled some form of memory management policy 
 such as reserving memory for the GC to use.
Yeah, that’s what I regularly do in C++ when I need to efficiently create/destroys many small objects. Sure, this typically leads to the best performance, e.g. because I can make the memory layout as cache friendly as humanly possible. But not all projects need that. And even for very performance demanding apps, not all components of the app need that. For such cases, a good GC (that just works well out of the box like .NET's GC does) can reduce development costs significantly.
Jun 15 2016
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 16/06/2016 6:53 AM, Konstantin wrote:
 On Wednesday, 15 June 2016 at 17:02:11 UTC, rikki cattermole wrote:

 Higher level languages like Java have the benefit of using pools and
 optimizing for this usage pattern, D does and will never have this.
Why don't you want the same for D?
Because we don't need them. Sprinkling of fairy dust is for stories, not reality.
 Well if you really insist to have a String class don't be too
 surprised for some reason it doesn't have the same performance to say
 Java.
Some areas, like compiling, or producing HTML/XML/JSON documents, manipulate strings a lot. Other areas, like GUI editors for sufficiently complex documents, or level editors for videogame, need to efficiently manipulate huge trees of assorted small objects, not necessarily strings.
You're quite right and that is why we have a GC to begin with. Its also part of the reason why std.experimental.allocator will allow you to create an allocator that is able to handle such work load and then free when complete.
 Aka don't go around creating/destroying classes a huge amount unless
 you have rolled some form of memory management policy such as
 reserving memory for the GC to use.
Yeah, that’s what I regularly do in C++ when I need to efficiently create/destroys many small objects. Sure, this typically leads to the best performance, e.g. because I can make the memory layout as cache friendly as humanly possible. But not all projects need that. And even for very performance demanding apps, not all components of the app need that. For such cases, a good GC (that just works well out of the box like .NET's GC does) can reduce development costs significantly.
So exactly like what our GC does do. Unless you're doing real time development in any form (e.g. sound) you won't need to do much to work around the GC.
Jun 15 2016
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:
 Has anyone thought about taking GC from .NET and reusing it in 
 D?
Fast GC for D was considered and rejected. What can be done is a precise and concurrent GC.
Jun 15 2016
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:
 I don’t believe a community is capable of creating a good GC.
you are wrong. and you definitely know nothing about garbage collection, virtual machines and code generation. i wonder why people keep coming with "suggestions" and "solutions" without even a small knowledge in problem field.
Jun 15 2016
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Wednesday, 15 June 2016 at 13:38:33 UTC, ketmar wrote:
 On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:
 I don’t believe a community is capable of creating a good GC.
you are wrong. and you definitely know nothing about garbage collection, virtual machines and code generation. i wonder why people keep coming with "suggestions" and "solutions" without even a small knowledge in problem field.
That's pretty harsh Ketmar. It's obvious he knows the general ideas and was just wondering if using the .NET GC was a viable option. I think responding to others in such a demeaning way is harmful to the D community as it isolates people. It doesn't encourage people to be curious or want to start a discussion. Having people, especially newcomers to D come in and make suggestions and solutions is a great thing for a community. It means they saw enough potential in the language to want to know more and maybe even how they could contribute.
Jun 16 2016
parent reply Joerg Joergonson <JJoergonson gmail.com> writes:
On Friday, 17 June 2016 at 04:20:23 UTC, Jonathan Marler wrote:
 On Wednesday, 15 June 2016 at 13:38:33 UTC, ketmar wrote:
 On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:
 [...]
you are wrong. and you definitely know nothing about garbage collection, virtual machines and code generation. i wonder why people keep coming with "suggestions" and "solutions" without even a small knowledge in problem field.
That's pretty harsh Ketmar. It's obvious he knows the general ideas and was just wondering if using the .NET GC was a viable option. I think responding to others in such a demeaning way is harmful to the D community as it isolates people. It doesn't encourage people to be curious or want to start a discussion. Having people, especially newcomers to D come in and make suggestions and solutions is a great thing for a community. It means they saw enough potential in the language to want to know more and maybe even how they could contribute.
It also makes ketmar look like a tard and childish. Konstantin said he 'believed' something then ketmar responded with a fallacious attack. Maybe ketmar needs to take his meds? ;)
Jun 17 2016
parent dewitt <dkdewitt gmail.com> writes:
On Friday, 17 June 2016 at 21:47:36 UTC, Joerg Joergonson wrote:
 On Friday, 17 June 2016 at 04:20:23 UTC, Jonathan Marler wrote:
 On Wednesday, 15 June 2016 at 13:38:33 UTC, ketmar wrote:
 On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:
 [...]
you are wrong. and you definitely know nothing about garbage collection, virtual machines and code generation. i wonder why people keep coming with "suggestions" and "solutions" without even a small knowledge in problem field.
That's pretty harsh Ketmar. It's obvious he knows the general ideas and was just wondering if using the .NET GC was a viable option. I think responding to others in such a demeaning way is harmful to the D community as it isolates people. It doesn't encourage people to be curious or want to start a discussion. Having people, especially newcomers to D come in and make suggestions and solutions is a great thing for a community. It means they saw enough potential in the language to want to know more and maybe even how they could contribute.
It also makes ketmar look like a tard and childish. Konstantin said he 'believed' something then ketmar responded with a fallacious attack. Maybe ketmar needs to take his meds? ;)
The idea that "a community" cannot create a GC is false. It is not too complex as there are plenty of complex projects that are community driven. A better assumption would be he doesn't believe THIS community can create a GC. Not that I believe either because there is no reason a community driven GC would not be successful. There are plenty of good GCs out there like Java's for instance and work great for the ecosystem of the language but even if we had the greatest then some D devs would still be upset because a lot of D devs come from C/C++ and do not want the GC. Both statements made assumptions and I do not think they are even close to the worst things said on this forum. ppl chill a little. Light one up, Drink one, put some rounds down range, whatever you gotta do to lighten up a little.
Jun 17 2016
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:
 I don’t believe a community is capable of creating a good GC. 
 It’s just too complex engineering task. It’s been a known 
 problem for years, still no solution.
GCs are a solved problem and the most common and fastest techniques have been known for more than 20 years. The GC implementation that D is using now came from the 70's, for example. One guy wrote the LuaJIT GC, which beat almost everyone else in performance when I last checked, so I think this is a massive exaggeration.
 Has anyone thought about taking GC from .NET and reusing it in 
 D?
Two words: write barriers.
Jun 15 2016
parent reply Konstantin <soonts gmail.com> writes:
On Wednesday, 15 June 2016 at 13:56:09 UTC, Jack Stouffer wrote:

 One guy wrote the LuaJIT GC, which beat almost everyone else in 
 performance when I last checked
“The current garbage collector is relatively slow compared to implementations for other language runtimes. It's not competitive with top-of-the-line GCs, especially for large workloads.“ https://github.com/LuaJIT/LuaJIT/issues/38 They have planned something for 3.0 that may or may not work: http://wiki.luajit.org/New-Garbage-Collector But that’s merely a design, AFAIK there’s no implementation. They’re still looking for a sponsor for that.
 Has anyone thought about taking GC from .NET and reusing it in 
 D?
Two words: write barriers.
What about them? You mean not all D’s target platforms support them?
Jun 15 2016
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 15 June 2016 at 17:03:21 UTC, Konstantin wrote:
 Two words: write barriers.
What about them? You mean not all D’s target platforms support them?
They're not acceptable for a systems programming language as they require you to pay for something that you might not use. According to our resident GC maintainer (among many other things), they would cause a 1%-5% slow down in the language: https://github.com/dlang/druntime/pull/1081#issuecomment-69151660
Jun 15 2016
parent reply Konstantin <soonts gmail.com> writes:
On Wednesday, 15 June 2016 at 18:23:52 UTC, Jack Stouffer wrote:

 They're not acceptable for a systems programming language as 
 they require you to pay for something that you might not use.

 According to our resident GC maintainer (among many other 
 things), they would cause a 1%-5% slow down in the language: 
 https://github.com/dlang/druntime/pull/1081#issuecomment-69151660
Well I’m not sure about the 5% (MS says their write barrier overhead is comparable to the cost of a simple method call, namely 6.4ns: https://msdn.microsoft.com/en-us/library/ms973852.aspx), but yeah, there’s some tradeoff, for having a good GC. By the way, Go implemented those barriers in version 1.5 a year ago: https://blog.golang.org/go15gc
Jun 15 2016
next sibling parent cym13 <cpicard openmailbox.org> writes:
On Wednesday, 15 June 2016 at 19:39:59 UTC, Konstantin wrote:
 On Wednesday, 15 June 2016 at 18:23:52 UTC, Jack Stouffer wrote:

 They're not acceptable for a systems programming language as 
 they require you to pay for something that you might not use.

 According to our resident GC maintainer (among many other 
 things), they would cause a 1%-5% slow down in the language: 
 https://github.com/dlang/druntime/pull/1081#issuecomment-69151660
Well I’m not sure about the 5% (MS says their write barrier overhead is comparable to the cost of a simple method call, namely 6.4ns: https://msdn.microsoft.com/en-us/library/ms973852.aspx), but yeah, there’s some tradeoff, for having a good GC. By the way, Go implemented those barriers in version 1.5 a year ago: https://blog.golang.org/go15gc
May I point out that you do not seem to have any kind of experience of D's GC? Try it and see for yourself wether it actually stops you or not. It's right that not everyone is pleased with the current GC but those users have specific expectations and I'm not certain at all that they would find C# or Go's GC acceptable either. The point is, D doesn't have to have a GC. Not using it is way easier than in most other languages because all the tools to help you profile it and avoid it are provided by the compiler. Go without a good GC is a dead language. D without a good GC is just not as good as it could be. And btw we're generally faster than Go ;-) The point is: while a better GC is a work in progress we'll *never* have a GC that can fit all needs, but it's not as critical as it is in Go or in C# because we provide other ways to manage memory when limitations arise.
Jun 15 2016
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 15 June 2016 at 19:39:59 UTC, Konstantin wrote:
 Well I’m not sure about the 5% (MS says their write barrier 
 overhead is comparable to the cost of a simple method call, 
 namely 6.4ns: 
 https://msdn.microsoft.com/en-us/library/ms973852.aspx), but 
 yeah, there’s some tradeoff, for having a good GC.
Even 1% overhead is unacceptable. Again, it's not reasonable for a systems language to have people pay for things they're not using. Write barriers will come to D over Walter's dead body.
 By the way, Go implemented those barriers in version 1.5 a year 
 ago: https://blog.golang.org/go15gc
Go has no allocation strategies but the GC, so that point is moot.
Jun 15 2016
parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 15 June 2016 at 20:22:21 UTC, Jack Stouffer wrote:
 On Wednesday, 15 June 2016 at 19:39:59 UTC, Konstantin wrote:
 Well I’m not sure about the 5% (MS says their write barrier 
 overhead is comparable to the cost of a simple method call, 
 namely 6.4ns: 
 https://msdn.microsoft.com/en-us/library/ms973852.aspx), but 
 yeah, there’s some tradeoff, for having a good GC.
Even 1% overhead is unacceptable. Again, it's not reasonable for a systems language to have people pay for things they're not using. Write barriers will come to D over Walter's dead body.
Simple exercise. You have 100 000 servers. Your application suddenly become 1% slower. How angry is your CFO when he discovers how many new machines he needs to buy ?
Jun 15 2016
parent Observer <here inter.net> writes:
On Wednesday, 15 June 2016 at 20:43:55 UTC, deadalnix wrote:
 Simple exercise. You have 100 000 servers. Your application 
 suddenly become 1% slower. How angry is your CFO when he 
 discovers how many new machines he needs to buy ?
Probably not too angry at all. This is still just a 1% budget increase, which amounts to a rounding error. Say those 100K servers cost $2K each, meaning $200M for the lot. An extra $2M capital costs doesn't mean much in that context. Perhaps a bigger issue might be the ongoing extra cost for energy, which applies to all the machines, not just tne new ones. Look at it another way. Anyone running 100_000 machines will certainly not be running them all flat-out, to where a 1% increase will push out a requirement for more machines. One needs extra capacity anyway to handle usual surges in the volume of business being handled by the servers. Look at it yet another way. Sure, $2M is a big number in absolute terms, for most of us. But if I were that CFO, instead of yelling about the problem, I'd go to the CTO and tell him to take 100 machines out of service and have the developers use them to profile the application and find places where much more than 1% can be saved.
Jun 18 2016
prev sibling parent reply Edwin van Leeuwen <edder tkwsping.nl> writes:
On Wednesday, 15 June 2016 at 17:03:21 UTC, Konstantin wrote:
 On Wednesday, 15 June 2016 at 13:56:09 UTC, Jack Stouffer wrote:
 Has anyone thought about taking GC from .NET and reusing it 
 in D?
Two words: write barriers.
What about them? You mean not all D’s target platforms support them?
I think he meant that the .NET GC (and most GC designs) rely on write barriers, but D does not have write barriers, since D is meant to be a proper systems language.
Jun 15 2016
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 15 June 2016 at 18:28:42 UTC, Edwin van Leeuwen 
wrote:
 I think he meant that the .NET GC (and most GC designs) rely on 
 write barriers, but D does not have write barriers, since D is 
 meant to be a proper systems language.
My reading of that LuaJIT GC document is that it requires write barriers, but that they are very cheap.
Jun 15 2016
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 15 June 2016 at 18:48:28 UTC, jmh530 wrote:
 My reading of that LuaJIT GC document is that it requires write 
 barriers, but that they are very cheap.
...for language that was originally VM-based. yet they'll have a noticable impact on language like D -- especially when programmer want to opt-out GC.
Jun 15 2016
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Wednesday, 15 June 2016 at 18:48:28 UTC, jmh530 wrote:
 On Wednesday, 15 June 2016 at 18:28:42 UTC, Edwin van Leeuwen 
 wrote:
 I think he meant that the .NET GC (and most GC designs) rely 
 on write barriers, but D does not have write barriers, since D 
 is meant to be a proper systems language.
My reading of that LuaJIT GC document is that it requires write barriers, but that they are very cheap.
Problem is, in D, many people want to NOT use a GC, and this is something we want to support. These people also do NOT want to pay for write barrier they do not use. That being said, we can do write barrier leveraging MMU on immutable (it'd be too expensive to do it on mutable data) during collection only, so that people that do not want to use the GC do not pay for it. The technique is used successfully in the ML family of languages for ages now with great results. Generally, I think the right path forward for D's GC is not to emulate managed language's GC as this clearly won't be acceptable for many users. On the other hand, we should: 1/ Leverage D's type system as to get infos about mutability/thread locality and segregate the heap accordingly/use adapted technique for each. 2/ Make sure the GC can deliver malloc grade performance in an alloc/free scenario, as to enable hybrid approach and allow people to rely on the GC to the extent they are willing to pay for. jemalloc internal datastructures are very amendable to build a GC. I started using this approach in SDC's GC. The only thing preventing me to move faster here is simply the time I can allocate to solve that problem.
Jun 15 2016
prev sibling parent thedeemon <dlang thedeemon.com> writes:
On Wednesday, 15 June 2016 at 13:19:31 UTC, Konstantin wrote:

 Has anyone thought about taking GC from .NET and reusing it in 
 D?
One significant point has been already mentioned: cost of write barriers. I'd like to mention another factor: .NET GC is a copying one, it moves data around. One good feature of current D is it never moves data, so you can very easily call C and C++ code and pass pointers to your buffers and stuff and C/C++ code just takes these pointers and works with them as usual. No pinning, no marshaling, zero overhead. If you take a moving GC like .NET's, you immediately make all C/C++ interaction much harder, now you need to worry about pinning stuff or copying "managed" data to "unmanaged" memory and back. This is all costly both in terms of CPU cycles and of programmer cycles. You'll need "FFI", what most other GC-ed languages have to have, and D doesn't.
Jun 16 2016