Re: D semantics, shared as a heap storage specifier

[Etienne via Digitalmars-d]

On 2014-12-08 11:36 AM, Dicebot wrote:

On Monday, 8 December 2014 at 15:07:48 UTC, John Colvin wrote:

On Monday, 8 December 2014 at 14:48:28 UTC, Etienne wrote:

So, nobody is in favor of extending the shared attribute for heap
storage?


I think people are a bit distracted with the scope proposal at the
moment.


Yes, there are just too many (potentially conflicting) things happening
right now, sorry.


It's alright, I'll figure out a way to fit it into a private branch so I 
can at least do it for myself.

Re: D semantics, shared as a heap storage specifier

[Dicebot via Digitalmars-d]

On Monday, 8 December 2014 at 15:07:48 UTC, John Colvin wrote:

On Monday, 8 December 2014 at 14:48:28 UTC, Etienne wrote:
So, nobody is in favor of extending the shared attribute for 
heap storage?


I think people are a bit distracted with the scope proposal at 
the moment.


Yes, there are just too many (potentially conflicting) things 
happening right now, sorry.

Re: D semantics, shared as a heap storage specifier

[John Colvin via Digitalmars-d]

On Monday, 8 December 2014 at 14:48:28 UTC, Etienne wrote:
So, nobody is in favor of extending the shared attribute for 
heap storage?


I think people are a bit distracted with the scope proposal at 
the moment.

Re: D semantics, shared as a heap storage specifier

[Etienne via Digitalmars-d]

So, nobody is in favor of extending the shared attribute for heap storage?

D semantics, shared as a heap storage specifier

[Etienne Cimon via Digitalmars-d]

This is the only issue preventing a truly thread-local GC for better 
multi-core scalability for D applications. From: 
https://github.com/D-Programming-Language/druntime/pull/1057#issuecomment-65904128


The best way to achieve a thread-local GC would be to improve and 
enforce `shared`-correctness in Phobos/druntime (at first). We need to 
start considering `shared` as a heap storage attribute as well, for 
consistency. An optional compiler warning (through a flag) would be a 
start.


If even a 30% speedup is possible down the line, it's worth it. The more 
threads, the more improvements.


There's also some new opportunities with this. Here's an example that 
involves TLS data to influence the behavior of shared objects, without 
using a global `T[Thread]` hashmap.


```D
shared class A {
private bool m_init; // different on every thread

public shared:
AA m_impl;

synchronized void init() {
if (!m_init)
m_impl.add(Thread.getThis());
}

...


}
```