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

What is it about Windows that makes you call it a distant possibility? Is it just that you are unfamiliar with it or is there some specific OS level feature you plan on needing?

On 06/19/2017 03:35 PM, 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

Very informative, thanks.

However, I can think of many reasons like appreciation the efforts of the original authors to tone it down a little bit like changing "mistake" to "optimization opportunity", "criticism" to "observation", etc. :)

Ali

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.

Looks like I'm not the only one itching to have a go at D's GC :) This will very likely be my DConf 2018 project. However, I have slightly different plans:

- The GC should be usable as a library (mainly to facilitate testing).
- Support for all platforms D already supports from the start.
- Use design-by-introspection when applicable and design-by-contract elsewhere to split the design into modular components.
- Make the GC configurable (using policies) and swappable at runtime. (No need to get clever, just treat previous implementation's pools as opaque void[]).
- Support concurrency on Windows via anonymous memory-mapped files.
- Support generational collection using write barriers implemented through memory protection.
- Integrate existing GC work - don't reinvent the wheel.
- More, much more debugging facilities! Integrate Diamond and Valgrind interoperability.
- Gray-marking and compacting.
- Still need to look at immix.

I have some past work that I'd like to integrate (an experimental generational GC I wrote like 9 years ago for D1, Diamond, and Valgrind integration I have in a fork somewhere.)

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

> if not a single pool is capable to service an allocation a new pool is allocated

should probably be
"if a single pool is not capable of servicing ..."

Looove the figures! Looking forward to seeing the results.

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

Good overview, however:
the binary search pool lookup is used because it naturally supports variable sized pools.
IMHO, simply concluding "A hash table could have saved quite a few cycles." glosses over the issue of handling variable sizes.

On Monday, 19 June 2017 at 23:39:54 UTC, H. S. Teoh wrote:
> On Mon, Jun 19, 2017 at 10:50:05PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
>> What is it about Windows that makes you call it a distant possibility? Is it just that you are unfamiliar with it or is there some specific OS level feature you plan on needing?
>
> AFAIK, Windows does not have equivalent functionality to this.
>

I've read that there is such a function on Windows but you need to use undocumented/unofficial API to access it:

e.g. https://github.com/opencollab/scilab/blob/master/scilab/modules/parallel/src/c/forkWindows.c

safety0ff wrote:

> On Monday, 19 June 2017 at 23:39:54 UTC, H. S. Teoh wrote:
>> On Mon, Jun 19, 2017 at 10:50:05PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
>>> What is it about Windows that makes you call it a distant possibility? Is it just that you are unfamiliar with it or is there some specific OS level feature you plan on needing?
>>
>> AFAIK, Windows does not have equivalent functionality to this.
>>
>
> I've read that there is such a function on Windows but you need to use undocumented/unofficial API to access it:
>
> e.g. https://github.com/opencollab/scilab/blob/master/scilab/modules/parallel/src/c/forkWindows.c

it is higly depends of undocumented windows internals, and not portable between windows versions. more-or-less working implementations of `fork()` were existed at least since NT3 era, but nobody considered 'em as more than a PoC, and even next service pack can break everything.

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

"...the dubious optimization of no interior pointers..."

this is the ONLY (i emphasise it!) way i were able to make my e-mail and irc clients to not leak memory, and keep using GC. on 32-bit systems false pointers *is* a problem, and NO_INTERIOR really helps.

turning NO_INTERIOR into something dog-slow (or noop) will make D unusable on 32-bit systems for anything more complex than helloworld and throwaway scripts. particularly, any app that should work for weeks or monthes without restart (yep, i want my mail client to Just Work, and i'm not rebooting my PC that often) will be *forced* to ditch GC.

while NO_INTERIOR requires some coding discipline, it is invaluable in IRL apps.

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

This was posted on reddit: https://www.reddit.com/r/programming/comments/6ic52d/inside_ds_gc/