On Tuesday, 20 June 2017 at 15:16:01 UTC, Ecstatic Coder wrote:
> This is probably why Nim's author was once paid to wrap an open source game engine (Urho3D), and improve the language's native compatibility with C++ libraries.
>
> https://forum.nim-lang.org/t/870

https://github.com/3dicc/Urhonimo/blob/master/Urho3D-1.32/Source/Engine/Container/Str.h
http://dbartolini.github.io/crown/doxygen/structcrown_1_1_dynamic_string.html

Is it always like this?

On Monday, 19 June 2017 at 22:35:42 UTC, Dmitry Olshansky wrote:
>
> http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html
>
> "But the main unanswered question is why? Why an extra pass?"

It's likely to pave over the many pitfalls of D finalizers.

E.g. finalizers corrupting data:
class A { size_t i; }
class B { A a; this(){ a = new A; } ~this() { a.i = 1; } }
// modifying B.a.i is undefined behavior (e.g. it could corrupt the GC's freelist)

E.g. finalizers reading undefined data:
class A { virtual bool check() { return true; } }
class B { A a; this(){ a = new A; } ~this() { a.check(); } }
// B.a's object header is undefined (e.g. replaced with GC freelist pointer)

There's also invariants, which are prepended to the finalizers, so their code is subject to the same issues.

The best thing about the current implementation is that object resurrection has never been supported.

On Monday, 19 June 2017 at 22:35:42 UTC, Dmitry Olshansky wrote:
> My take on D's GC problem, also spoiler - I'm going to build a new one soonish.
>
> http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html
>
> ---
> Dmitry Olshansky

FYI, we've tried to improve the binary pool search, but there aren't many pools and it's quite hard to beat.
A hashtable for a pages in the address range is too big.
I'd like to replace all of those separate pools types with a single page heap, similar to what TCMalloc is using.
http://goog-perftools.sourceforge.net/doc/tcmalloc.html
http://jamesgolick.com/2013/5/19/how-tcmalloc-works.html

There was also https://github.com/dlang/druntime/pull/801 which got reverted.

One problem that you'll run into with a Thread cache is synchronizing GC attributes.
In the stalled work on a thread-cache for the current GC. Using single-reader single-writer queues to would've been an option there to reduce contention.

https://github.com/MartinNowakhttps://github.com/dlang/druntime/compare/master...MartinNowak:gcCache#commitcomment-16202536

On Saturday, 24 June 2017 at 15:31:21 UTC, Martin Nowak wrote:
> On Monday, 19 June 2017 at 22:35:42 UTC, Dmitry Olshansky wrote:
>> My take on D's GC problem, also spoiler - I'm going to build a new one soonish.
>>
>> http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html
>>
>> ---
>> Dmitry Olshansky
>
> FYI, we've tried to improve the binary pool search, but there aren't many pools and it's quite hard to beat.
> A hashtable for a pages in the address range is too big.

Doesn't have to be for pages. Pool granularity is 256k, aligning the pools at this boundary is enough. On x64 pool granularity could be enlarged.


> I'd like to replace all of those separate pools types with a single page heap, similar to what TCMalloc is using.
> http://goog-perftools.sourceforge.net/doc/tcmalloc.html
> http://jamesgolick.com/2013/5/19/how-tcmalloc-works.html
>

I still think that separate pool types is better, see eg jemalloc.

On Saturday, 24 June 2017 at 18:12:43 UTC, Dmitry Olshansky wrote:
> I still think that separate pool types is better, see eg jemalloc.

Right now this leads to some inflation of RSS cause previously used and now freed pages can only be reused when the whole pool (e.g. 4MB or 16MB) is free again.
It doesn't seem sensible to reserve 16MB only for big (>PAGESIZE) allocations. In particular once the pages are dirty and mapped, you'd rather want to make use of them.

On Tuesday, 20 June 2017 at 11:49:49 UTC, Jacob Carlborg wrote:
> You need to move to 64bit. Apple is already deprecating support for 32bit apps and after the next version of macOS (High Sierra) they're going to remove the support for 32bit apps.

There are other 32-bit platforms that are going to stay on the market for a while. 32-bit ARMs won't disappear anytime soon.

On 2017-06-25 17:47, Adrian Matoga wrote:

> There are other 32-bit platforms that are going to stay on the market
> for a while. 32-bit ARMs won't disappear anytime soon.

Sure, but as I mentioned I mixed up ketmar and Guillaume Piolat and Guillaume Piolat is using Apple platforms, as far as I understand.

-- 
/Jacob Carlborg