September 13, 2014 Re: [Article] D's Garbage Collector Problem | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marc Schütz | On 09/13/2014 09:07 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> Wouldn't `const` be enough? AFAICS, `immutable` is mostly useful for
> shared data.
const prevents modification, but does not guarantee that no modification takes place elsewhere. I.e. it enables fewer program transformations.
|
September 13, 2014 Re: [Article] D's Garbage Collector Problem | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marc Schütz | And strong purity. |
September 13, 2014 Re: [Article] D's Garbage Collector Problem | ||||
---|---|---|---|---|
| ||||
Posted in reply to Marco Leise | On Thursday, 11 September 2014 at 16:26:37 UTC, Marco Leise wrote:
> Shared/unshared may affect implementations that provide thread
> local GC. E.g. only shared data needs to be handled by a
> global stop the world GC. I'm not sure though.
Also a certain discipline is required to construct shared/immutable object from the start instead of casting from thread-local mutable. And then how to add an object to a shared collection?
//callable without lock
void add(shared Object) shared;
//allocated thread-local object
void add(Object);
//but unshared collection contains unshared objects
void add(shared Object);
//thread-local object again
void add(Object) shared;
?
|
September 14, 2014 Re: [Article] D's Garbage Collector Problem | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Saturday, 13 September 2014 at 19:20:51 UTC, Timon Gehr wrote:
> On 09/13/2014 09:07 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
>> Wouldn't `const` be enough? AFAICS, `immutable` is mostly useful for
>> shared data.
>
> const prevents modification, but does not guarantee that no modification takes place elsewhere. I.e. it enables fewer program transformations.
But as it is thread-local, is it really relevant (for optimization)? I can see two situations where it can potentially matter: pointer parameter aliasing, and calls to function/delegate calls that might modify a value referenced by a pointer.
In practice the latter is probably not so important for optimizations, because the compiler would most likely have a hard time caching a value across a function call because of register pressure, so a reload would be necessary anyway. I don't know about parameter aliasing, but I guess it only makes a difference in corner cases. In these cases, it's easy to forbid it by contract (as slice copying does).
|
Copyright © 1999-2021 by the D Language Foundation