February 02, 2014 Re: Smart pointers instead of GC? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 2/2/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote: > 2. Work on Phobos to see what can be done about avoiding unnecessary allocation. Most likely we'll need to also add a @nogc flag. See Johannes'es pull here: https://github.com/D-Programming-Language/dmd/pull/1886 Where he comments: ``` Note: This could also be a start to implement a -nogc parameter which would check a whole module not to use the GC. This is less intrusive than a @nogc attribute. ``` |
February 02, 2014 Re: Smart pointers instead of GC? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 02/02/2014 05:55 PM, Andrei Alexandrescu wrote:
>
> I think of the following foci for the first half of 2014:
>
> 1. Add @nullable and provide a -nullable compiler flag to verify it. The
> attribute is inferred locally and for white-box functions (lambdas,
> templates), and required as annotation otherwise. References not
> annotated with @nullable are statically enforced to never be null.
- I assume that also, references annotated with @nullable are statically enforced to never be dereferenced?
- how to eg. create an array of nullable references? struct Nullable!T{ @nullable T t; alias t this; } Nullable!T[] foo; ? I think that would cause problems with IFTI.
|
February 02, 2014 Re: Smart pointers instead of GC? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 02/02/2014 06:55 PM, Timon Gehr wrote:
> struct Nullable!T
struct Nullable(T). Non-uniformity of declaration and usage...
|
February 02, 2014 Re: Smart pointers instead of GC? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | Am Sun, 2 Feb 2014 18:36:29 +0100
schrieb Andrej Mitrovic <andrej.mitrovich@gmail.com>:
> On 2/2/14, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> > 2. Work on Phobos to see what can be done about avoiding unnecessary allocation. Most likely we'll need to also add a @nogc flag.
>
> See Johannes'es pull here: https://github.com/D-Programming-Language/dmd/pull/1886
>
> Where he comments:
>
> ```
> Note: This could also be a start to implement a -nogc parameter which
> would check a whole module not to use the GC. This is less intrusive
> than a @nogc attribute.
> ```
The last iteration actually implements -nogc and the pull request also provides almost everything needed for @nogc. The attribute should probably be added in a second pull request as I expect more discussions there.
|
February 02, 2014 Re: Smart pointers instead of GC? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | On Sun, 02 Feb 2014 06:48:28 -0800, Paulo Pinto <pjmlp@progtools.org> wrote: > Am 02.02.2014 15:11, schrieb Adam D. Ruppe: >> On Sunday, 2 February 2014 at 11:23:56 UTC, JR wrote: >>> I *seem* to remember reading here that you and Walter were >>> increasingly growing to favor ARC, but I can't find the post. >> >> Personally, I think ARC is a waste of time and none of the arguments >> I've seen for it are convincing. Improving the Gc implementation would >> be a much bigger win. > > It might be that ARC will be a solution given the recent work in Objective-C, ParaSail, Rust and the misterious M#. > > I was even surprised to discover that Cedar actually used RC with a GC just for collecting cycles. > > What I don't like is using Objective-C as a poster child for ARC, because the only reason it exists, is that Apple engineers weren't able to write a GC for Objective-C that didn't core dump left and right. > > Apple of course sold the history in a different way. > > -- > Paulo I just want to point out that in the comments of Joe Duffy's latest post on M# he explicitly stated that M# is still C# semantics, and specifically he says that all existing C# code will compile with M#, since ARC would by very fact of it's nature require the language semantics to change, it's extremely unlikely that M# will use ARC. Especially since they have access to a GC guru. For a ridiculously easy example, what do you do when one object implements .Dispose() and another one does not? -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator |
February 02, 2014 Re: Smart pointers instead of GC? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | On 2/2/14, Johannes Pfau <nospam@example.com> wrote:
> The last iteration actually implements -nogc and the pull request also provides almost everything needed for @nogc.
Excellent. 2014 is looking great so far. :>
|
February 02, 2014 Re: Smart pointers instead of GC? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 2/2/2014 8:55 AM, Andrei Alexandrescu wrote:
> 1. Add @nullable and provide a -nullable compiler flag to verify it. The
> attribute is inferred locally and for white-box functions (lambdas, templates),
> and required as annotation otherwise. References not annotated with @nullable
> are statically enforced to never be null.
I want to clarify that @nullable would be a storage class, NOT a type constructor. This means it will apply to the variable itself, not its type.
For example:
@nullable T* p;
auto q = p; // q is a T*, not @nullable
In a way, it would work much like ref, which is also a storage class and not a type constructor.
|
February 02, 2014 Re: Smart pointers instead of GC? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Namespace | On 2/2/2014 9:30 AM, Namespace wrote:
> Sounds good. But why @nullable instead of C# choice of "Type?" ?
Let me rephrase that as "why use a storage class rather than a type constructor?"
An excellent question.
One of the big problems with a type constructor is we've already got a number of them - const, immutable, shared, inout. These and their conversions have taken quite a while for people to get comfortable with, and there are still some issues in the language arising from their interactions.
Adding another type constructor will double the number of cases. I worry that D would collapse under the strain. This applies as well to type constructors for "borrowed", etc.
On the other hand, D took the risky leap into the unknown by making 'ref' a storage class rather than a type constructor (in C++ it's a type constructor). This has turned out to be a satisfying win. I suspect it will be for @nullable, too, though we have to work through the cases to find out for sure.
|
February 02, 2014 Re: Smart pointers instead of GC? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 2/2/2014 9:55 AM, Timon Gehr wrote:
> - how to eg. create an array of nullable references? struct Nullable!T{
> @nullable T t; alias t this; } Nullable!T[] foo; ? I think that would cause
> problems with IFTI.
@nullable being a storage class, this couldn't be done with @nullable just as you cannot create an array of 'ref' types.
|
February 02, 2014 Re: Smart pointers instead of GC? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | +1 on making Phobos GC-free.
On Sunday, 2 February 2014 at 07:35:21 UTC, Andrei Alexandrescu wrote:
> On 2/1/14, 10:00 PM, Frank Bauer wrote:
>> On Sunday, 2 February 2014 at 05:41:53 UTC, Andrei Alexandrescu wrote:
>>> Sure. While you're young typecheck this:
>>>
>>> class A {
>>> auto stuff() { ...; return this; }
>>> }
>>>
>>>
>>> Andrei
>>
>> It would be a Borrowed!A, I would say, no matter how an A is allocated.
>> A GC!A, an ARC!A and an Owning!A convert equally well to a Borrowed!A.
>> As long as the Borrowed!A is in use (i.e. scope) after stuff() returns,
>> the A object must not be freed (compiler enforced). Would that make sense?
>
> No.
>
> What I'm driving at is that right now the type is A, as is in a variety of other situations. It would be a whole different language that would be wholly incompatible with D.
>
>
> Andrei
Why is that? I propose the new memory regime to be 100% compatible with all existing D code. It is way more powerful than anything scope can do. And it seems a lot less work to me than going through GC optimization and custom allocator tracing hell.
Let's see how far we can get if we require none of the existing D code to break.
Example: this is current D code that runs unchanged and with the same semantics under the new memory regime. GC(T) and Borrowed(T) remain under the hood:
class A {
A foo() { return this; } // returns Borrowed!A
}
void main () {
A m1 = new A; // m1 is a GC!A
A m2 = m1; // m2 is a Borrowed!A
A m3; // Borrowed!A
m3 = m1; // fine: assignment from GC!A to Borrowed!A
m3 = bar(m1); // fine: m1 converted from GC!A to Borrowed!A, assignment from Borrowed!A to Borrowed!A
m3 = bar(m2); // fine: m2 already Borrowed!A, assignment from Borrowed!A to Borrowed!A
m1 = new A; // fine: can reasssign GC!A although there are outstanding references
m1 = m2; // fine: can reassign GC!A to a Borrowed!A
}
A bar(A a) { // takes and returns Borrowed!A
A b1 = a;
return b1;
}
Now here it comes: if, on the other hand, I replace the first 'new' with, say e.g., 'newOwning' (or '~', whatever), I get GC-free code:
A m1 = newOwning A; // m1 is an Owning!A, allocating on the heap and freeing when it goes out of scope
Then these lines above would be in error:
m1 = new A; // error: can't reassign to m1 because m2 and m3 still referencing m1 (same for newOwning)
m1 = m2; // error: can't assign Borrowed!A to Owning!A
ARC(T) could be implemented similarly.
Nothing changes one bit for those who want to use the GC as before. ARC(T) and Owning(T) would be *ADDED* on top of the existing language spec.
Emplacement new, as Adam mentioned, is not a problem: you always get to the emplaced object with a Borrowed!T. The underlying memory is managed separately and automatically as a GC!M, ARC!M or Owning!M (M could be an array of bytes, e.g.).
|
Copyright © 1999-2021 by the D Language Foundation