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