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?

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.

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.

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.

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

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...)