www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Shared and GC

reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
I am trying to understand the idea behind "shared" typing fully.

If I am only allowed to share objects with another thread if it 
is typed "shared", doesn't that imply that it should be allocated 
as shared too and only be allowed to contain pointers to "shared"?

That would be nice, because then a precise garbage collector 
could choose between local collection scans and global collection 
scans.

Is this the intended semantics for shared?
Jan 15 2015
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 15 January 2015 at 15:24:55 UTC, Ola Fosheim Grøstad 
wrote:

 I am trying to understand the idea behind "shared" typing fully.

 If I am only allowed to share objects with another thread if it 
 is typed "shared", doesn't that imply that it should be 
 allocated as shared too and only be allowed to contain pointers 
 to "shared"?


Yes, shared is transitive.

struct S { int* p; }
void main() {
	S s1;
	shared S s2 = s1;  // error, but ok if p is int.
}



 That would be nice, because then a precise garbage collector 
 could choose between local collection scans and global 
 collection scans.


I think something like this is part of the plan, but shared 
semantics are still up in the air.
Jan 15 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 15 January 2015 at 15:31:17 UTC, Peter Alexander 
wrote:

 On Thursday, 15 January 2015 at 15:24:55 UTC, Ola Fosheim 
 Grøstad wrote:

 That would be nice, because then a precise garbage collector 
 could choose between local collection scans and global 
 collection scans.


 I think something like this is part of the plan, but shared 
 semantics are still up in the air.


That sounds like a very important aspect of a plan to get fast GC 
without completely changing the language and non-gc performance.

I've looked at bit at how to do a fast stop-the-thread GC. 
Estimates on what the hardware supports (bandwidth and cache 
performance) suggests that it is possible to get acceptable rates 
for not-densely-linked heaps with some tweaks to semantics:

- shared-awareness in new-expressions to support local collection

- removing class-destructors

- locating traceable pointers to the same cachelines in class 
instances (negative offsets is the easy solution)


Then you cn use a ache-optimized collector using batched 
non-caching queues with prefetching to get bitmaps that fits in 
1st level cache without wrecking the cache for other threads and 
having collection dominated by cache misses.
Jan 15 2015
parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 15 January 2015 at 17:05:32 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 15 January 2015 at 15:31:17 UTC, Peter Alexander 
 wrote:

 On Thursday, 15 January 2015 at 15:24:55 UTC, Ola Fosheim 
 Grøstad wrote:

 That would be nice, because then a precise garbage collector 
 could choose between local collection scans and global 
 collection scans.


 I think something like this is part of the plan, but shared 
 semantics are still up in the air.


 That sounds like a very important aspect of a plan to get fast 
 GC without completely changing the language and non-gc 
 performance.

 I've looked at bit at how to do a fast stop-the-thread GC. 
 Estimates on what the hardware supports (bandwidth and cache 
 performance) suggests that it is possible to get acceptable 
 rates for not-densely-linked heaps with some tweaks to 
 semantics:

 - shared-awareness in new-expressions to support local 
 collection

 - removing class-destructors

 - locating traceable pointers to the same cachelines in class 
 instances (negative offsets is the easy solution)


 Then you cn use a ache-optimized collector using batched 
 non-caching queues with prefetching to get bitmaps that fits in 
 1st level cache without wrecking the cache for other threads 
 and having collection dominated by cache misses.


Yah, this was all discussed at length not that long ago, although 
I can't find the thread just now.
Jan 15 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
http://forum.dlang.org/thread/dnxgbumzenupviqymhrg forum.dlang.org 
:-/
Jan 18 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 18 January 2015 at 16:12:24 UTC, Kagamin wrote:

 http://forum.dlang.org/thread/dnxgbumzenupviqymhrg forum.dlang.org 
 :-/


:-/

I'm inclined to write a DIP... (or fork...)
Jan 19 2015