Analysis of D GC
Dmitry Olshansky via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jun 20 02:30:43 PDT 2017
On Monday, 19 June 2017 at 23:39:54 UTC, H. S. Teoh wrote:
> On Mon, Jun 19, 2017 at 10:35:42PM +0000, Dmitry Olshansky via
> Digitalmars-d 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
> [...]
>
> Very interesting indeed!
>
> One question about killing the no interior pointer attribute:
> would this be problematic for 32-bit platforms? And if so, what
> do you plan to do about it? Keep the current GC as
> version(32bit) and your new version as version(64bit)?
Yeah if said 32-bit application makes use of no interior pointer
attribute then using old gc is an option. I have no plans for
this broken attribute.
>
> One (potentially crazy) idea that occurred to me while reading
> your post is TLS allocations. I haven't thought through the
> details of how this would interact with the existing language
> yet, but would it make sense for some allocations that you know
> will never be shared across threads to be allocated in a
> thread-local pool instead of the global pool? I.e., in addition
> to the global set of memory pools you also have thread-local
> memory pools. Then you could potentially run collections
> per-thread rather than stop-the-world.
>
This needs spec updateon interaction between TLS and shared, in
particular the current trend of lock + cast away shared is
problematic. Also the implicit cast to immutable of a result of
unique expression.
>
> 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?
>
> He mentioned the "fork trick", which I assume refers to how
> Linux's implementation of fork() uses copy-on-write rather than
> immediately duplicating the parent process' memory structures.
> There was a D1 GC some time ago that depended on this behaviour
> to speed up the collection cycle. AFAIK, Windows does not have
> equivalent functionality to this.
To the best of my knowledge all of D's current target OSes
support this save for Windows.
>
> T
More information about the Digitalmars-d
mailing list