www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - compile time garbage collection

reply "Freddy" <Hexagonalstar64 gmail.com> writes:
How crazy hard would it be to have a front end optimization pass 
that would try to replace garbage collector calls with malloc / 
free?
May 02 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 02 May 2015 15:10:10 +0000, Freddy wrote:


 How crazy hard would it be to have a front end optimization pass that
 would try to replace garbage collector calls with malloc / free?


impossible.=
May 02 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 2 May 2015 at 16:13:36 UTC, ketmar wrote:

 On Sat, 02 May 2015 15:10:10 +0000, Freddy wrote:


 How crazy hard would it be to have a front end optimization 
 pass that
 would try to replace garbage collector calls with malloc / 
 free?


 impossible.


Not impossible, but if you can do it you probably often can 
replace it with a stack allocation. Though, if D gets 
"non-shared" semantics right and a high level intermediate 
representation with whole program optimization then it should be 
possible to do more. I.e. if you know that an object isn't 
accessed by another thread ever, then you have something easier 
to analyze.
May 02 2015
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 02 May 2015 16:24:15 +0000, Ola Fosheim Gr=C3=B8stad wrote:


 On Saturday, 2 May 2015 at 16:13:36 UTC, ketmar wrote:

 On Sat, 02 May 2015 15:10:10 +0000, Freddy wrote:


 How crazy hard would it be to have a front end optimization pass that
 would try to replace garbage collector calls with malloc / free?


 impossible.


=20
 Not impossible


oh, well, it is possible by adding RC and mark-and-sweep for loops. yet=20
this is cheating, 'cause it's the same old GC in different clothes. ;-)=
May 02 2015
prev sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Saturday, 2 May 2015 at 16:24:17 UTC, Ola Fosheim Grøstad 
wrote:

 Not impossible, but if you can do it you probably often can 
 replace it with a stack allocation.


AFAIK LDC already has a pass that does this, I'm not sure how 
well it works.
May 02 2015
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sun, 03 May 2015 04:40:42 +0000, weaselcat wrote:


 On Saturday, 2 May 2015 at 16:24:17 UTC, Ola Fosheim Gr=C3=B8stad wrote:

 Not impossible, but if you can do it you probably often can replace it
 with a stack allocation.


=20
 AFAIK LDC already has a pass that does this, I'm not sure how well it
 works.


i don't thing that such pass in general worth the efforts. D programmers=20
tend to use structures for local and short-lived objects. if i did `new`,=20
chances are that i really want it on heap, and it will not be optimisable=20
(i either returning pointer, or passing it to some function that stores=20
it somewhere).

so it can catch very rare cases for the cost of expensive interprocedural=20
analysis. this makes some sense for C++, though.=
May 02 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 3 May 2015 at 04:46:52 UTC, ketmar wrote:

 i don't thing that such pass in general worth the efforts. D 
 programmers
 tend to use structures for local and short-lived objects. if i 
 did `new`,
 chances are that i really want it on heap, and it will not be 
 optimisable


This is where one have to decide whether to make a low/system 
level language with programmer control or a high level language 
with compiler control.  If you have GC by default, then it makes 
a lot of sense to not even have a stack conceptually and do 
explicit allocations and stack allocation as an optimization.

But yeah, a system level language should allow threads to be 
terminated which would prevent destructors from being called, and 
since GC call destructors on another thread it will change 
program behaviour to turn GC allocations into stack allocations 
in general...


 so it can catch very rare cases for the cost of expensive 
 interprocedural
 analysis. this makes some sense for C++, though.


Well, if D is to be a higher level language than C++, then it 
makes more sense for D. Especially since a "threaded view" 
through "non-shared" objects could allow better analysis, but 
that would require a 100% ban on transferring "non-shared 
pointers" to "shared pointers".

D really needs to get a well defined memory model.
May 03 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 3 May 2015 at 08:02:37 UTC, Ola Fosheim Grøstad wrote:

 On Sunday, 3 May 2015 at 04:46:52 UTC, ketmar wrote:

 i don't thing that such pass in general worth the efforts. D 
 programmers
 tend to use structures for local and short-lived objects. if i 
 did `new`,
 chances are that i really want it on heap, and it will not be 
 optimisable


 This is where one have to decide whether to make a low/system 
 level language with programmer control or a high level language 
 with compiler control.  If you have GC by default, then it 
 makes a lot of sense to not even have a stack conceptually and 
 do explicit allocations and stack allocation as an optimization.

 But yeah, a system level language should allow threads to be 
 terminated which would prevent destructors from being called, 
 and since GC call destructors on another thread it will change 
 program behaviour to turn GC allocations into stack allocations 
 in general...


there's no guarantee GC allocated memory will _ever_ have their 
destructor ran, it's part of the spec.


The garbage collector is not guaranteed to run the destructor 
for all unreferenced objects.
May 03 2015
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 3 May 2015 at 08:22:31 UTC, weaselcat wrote:

 there's no guarantee GC allocated memory will _ever_ have their 
 destructor ran, it's part of the spec.


That would be very unfortunate, they have to either be called 
eventually or never called.  I find no such description in the 
"spec":

http://dlang.org/garbage.html

«5. Freeing all GC allocated memory that has no active pointers 
to it and do not need destructors to run.

6. Queueing all unreachable memory that needs destructors to run.

7. Resuming all other threads.

8. Running destructors for all queued memory.»
May 03 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Sunday, 3 May 2015 at 08:34:09 UTC, Ola Fosheim Grøstad wrote:

 On Sunday, 3 May 2015 at 08:22:31 UTC, weaselcat wrote:

 there's no guarantee GC allocated memory will _ever_ have 
 their destructor ran, it's part of the spec.


 That would be very unfortunate, they have to either be called 
 eventually or never called.  I find no such description in the 
 "spec":

 http://dlang.org/garbage.html

 «5. Freeing all GC allocated memory that has no active pointers 
 to it and do not need destructors to run.

 6. Queueing all unreachable memory that needs destructors to 
 run.

 7. Resuming all other threads.

 8. Running destructors for all queued memory.»


http://dlang.org/class.html#destructors
May 03 2015
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 3 May 2015 at 08:41:04 UTC, weaselcat wrote:

 http://dlang.org/class.html#destructors


Oh well, that should be described under GC too then, but it can 
improve collection speed so I guess it is ok if one requires 
classes to be marked  nogc if they have destructors.

The inbetween position is just dangerous.
May 03 2015
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 3 May 2015 at 04:40:44 UTC, weaselcat wrote:

 On Saturday, 2 May 2015 at 16:24:17 UTC, Ola Fosheim Grøstad 
 wrote:

 Not impossible, but if you can do it you probably often can 
 replace it with a stack allocation.


 AFAIK LDC already has a pass that does this, I'm not sure how 
 well it works.


If things do not escape and size is known, it works actually 
fairly well. Obviously, this kind of thing can only remove some 
allocations, but most will still ends up being freed by the GC.
May 02 2015