View mode: basic / threaded / horizontal-split · Log in · Help
December 18, 2011
Re: d future or plans for d3
On Sun, 18 Dec 2011 15:02:17 -0800, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 12/18/2011 11:53 PM, Vladimir Panteleev wrote:
>> On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu wrote:
>>> That is an interesting opportunity. At any rate, I am 100% convinced
>>> precise GC is the only way to go, and I think I've convinced Walter to
>>> a good extent as well.
>>
>> Sacrificing something (performance, executable size) for something else
>> is not an unilateral improvement.
>
> It is an unilateral improvement if both options are kept open. I don't  
> see a reason to cease support for the current GC model.
>
> Furthermore, a generational GC performs much better than a simple  
> mark-sweep GC.

It seems to that we are really dancing around the potential solution. A  
pluggable GC interface that allowed the developer to choose the right GC  
for the task, or no GC at all. Imagine if all the developer had to do is  
set a compiler switch and the compiler automatically linked in the correct  
GC for the job. D could ship with a default GC then others could write  
different GC's based on different paradigms or their own needs. It would  
be a piece of work to get the interfaces right, but definitely worth it in  
the long run.

Theoretically this would also give the developer the ability to link in  
multiple collectors and switch between them during program execution,  
provided the working set data was stored in a common format; although I  
have never heard of a use case for such a capability. I imagine that it  
could be useful if your application needs a low power state and you wanted  
to use a more power-efficient GC over a more precise one. I'm just  
theorizing here though. I'm sure their are technical snags that would  
prevent this from happening.

I think supporting a NoGC environment is a good idea in the long run as  
their are cases to be made for manual memory management, but it also  
shouldn't be our first goal. GC's are were the value is.

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
December 18, 2011
Re: d future or plans for d3
On 12/19/2011 12:16 AM, Andrei Alexandrescu wrote:
> On 12/18/11 5:11 PM, Vladimir Panteleev wrote:
>> Also, D can't have a completely precise
>> GC as long as it has unions and can pass managed memory to C code.
>
> Also casts pointer <-> integrals.

Casting a pointer to GC memory to an integral results in undefined behavior:
http://www.d-programming-language.org/garbage.html

>
> These arguments don't blunt the desirability of precise GC.
>
>
> Andrei
December 18, 2011
Re: d future or plans for d3
On Sunday, 18 December 2011 at 23:13:03 UTC, Andrei Alexandrescu 
wrote:
> On 12/18/11 4:53 PM, Vladimir Panteleev wrote:
>> On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei 
>> Alexandrescu wrote:
>>> That is an interesting opportunity. At any rate, I am 100% 
>>> convinced
>>> precise GC is the only way to go, and I think I've convinced 
>>> Walter to
>>> a good extent as well.
>>
>> Sacrificing something (performance, executable size) for 
>> something else
>> is not an unilateral improvement.
>
> I think we can do a lot toward improving the footprint and 
> performance of a precise GC while benefitting of its innate 
> advantages.

Still, a more conservative GC will always outperform a more 
precise one in scanning speed. Without knowing the price, it 
would be unwise to jump into it without even considering the 
possibility of leaving a choice.

I am not against the idea, but I believe that more research is 
needed before rash decisions are taken. If the performance 
penalty turns out to be insignificant, then choice would be 
pointless. And if there will be a considerable performance gap, 
the "burden" of choice (compiler switch/boolean runtime setting + 
maintenance costs) could be worth it.
December 18, 2011
Re: d future or plans for d3
Vladimir Panteleev:

> Also, D can't have a completely precise GC as long as it has unions

Despite C/D unions are untagged, in many cases there is some kind of manually managed tag (maybe stored elsewhere), or the programmer often knows (despite being sometimes wrong) what type is present inside the union at a given time. So I have suggested a standard optional  method for D unions, named onGC, that is called by the GC and informs the GC what type is present inside the union. So if you keep a union that is able to contain a size_t and a pointer, the onGC is able to tell the GC if in a given moment the union contains a pointer to follow in its search for alive objects, or an integral number to ignore.

Bye,
bearophile
December 18, 2011
Re: d future or plans for d3
On Sunday, 18 December 2011 at 23:18:22 UTC, Timon Gehr wrote:
> You are right. I have had in mind a generational GC that uses a 
> copying collector for the nursery as this is what most 
> state-of-the-art VM GCs do.
>
> ...
>
> We can change the way unions are layed out. The compiler can 
> mark GC memory passed to a C function as non-movable, or 
> passing GC memory to a C function can be made illegal if the GC 
> is enabled.

These changes are too invasive for the language at this point, I 
believe. We need to work with what we have.
December 18, 2011
Re: d future or plans for d3
On 12/18/11 5:22 PM, Vladimir Panteleev wrote:
> On Sunday, 18 December 2011 at 23:13:03 UTC, Andrei Alexandrescu wrote:
>> On 12/18/11 4:53 PM, Vladimir Panteleev wrote:
>>> On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu wrote:
>>>> That is an interesting opportunity. At any rate, I am 100% convinced
>>>> precise GC is the only way to go, and I think I've convinced Walter to
>>>> a good extent as well.
>>>
>>> Sacrificing something (performance, executable size) for something else
>>> is not an unilateral improvement.
>>
>> I think we can do a lot toward improving the footprint and performance
>> of a precise GC while benefitting of its innate advantages.
>
> Still, a more conservative GC will always outperform a more precise one
> in scanning speed.

I'm not sure. I seem to recall discussions with pathological cases when 
large regions of memory were scanned for no good reason.

> Without knowing the price, it would be unwise to jump
> into it without even considering the possibility of leaving a choice.

Sure.

> I am not against the idea, but I believe that more research is needed
> before rash decisions are taken. If the performance penalty turns out to
> be insignificant, then choice would be pointless. And if there will be a
> considerable performance gap, the "burden" of choice (compiler
> switch/boolean runtime setting + maintenance costs) could be worth it.

I ordered the GC book :o).


Andrei
December 18, 2011
Re: d future or plans for d3
On 12/18/11 5:18 PM, Timon Gehr wrote:
> On 12/19/2011 12:11 AM, Vladimir Panteleev wrote:
>> On Sunday, 18 December 2011 at 23:02:17 UTC, Timon Gehr wrote:
>>> It is an unilateral improvement if both options are kept open. I don't
>>> see a reason to cease support for the current GC model.
>>
>> I believe that currently the plan does not include providing this choice.
>>
>
> That would strike me as odd. Andrei/Walter?

The plan is in too early a stage to even discuss that choice.

>>> Furthermore, a generational GC performs much better than a simple
>>> mark-sweep GC.
>>
>> Unless you change the way references work, generational and "precise"
>> aspects of a GC are orthogonal.
>
> You are right. I have had in mind a generational GC that uses a copying
> collector for the nursery as this is what most state-of-the-art VM GCs do.
>
>> Also, D can't have a completely precise
>> GC as long as it has unions and can pass managed memory to C code.
>
> We can change the way unions are layed out. The compiler can mark GC
> memory passed to a C function as non-movable, or passing GC memory to a
> C function can be made illegal if the GC is enabled.

Unions will be conservative. The golden standard is that SafeD can't use 
them or anything that forces conservative approaches.


Andrei
December 18, 2011
Re: d future or plans for d3
On 12/19/2011 12:24 AM, Vladimir Panteleev wrote:
> On Sunday, 18 December 2011 at 23:18:22 UTC, Timon Gehr wrote:
>> You are right. I have had in mind a generational GC that uses a
>> copying collector for the nursery as this is what most
>> state-of-the-art VM GCs do.
>>
>> ...
>>
>> We can change the way unions are layed out. The compiler can mark GC
>> memory passed to a C function as non-movable, or passing GC memory to
>> a C function can be made illegal if the GC is enabled.
>
> These changes are too invasive for the language at this point, I
> believe. We need to work with what we have.

I disagree. Code that relies on other semantics would just have to use 
conservative GC.
December 18, 2011
Re: d future or plans for d3
On Sunday, 18 December 2011 at 23:31:03 UTC, Timon Gehr wrote:
> On 12/19/2011 12:24 AM, Vladimir Panteleev wrote:
>> On Sunday, 18 December 2011 at 23:18:22 UTC, Timon Gehr wrote:
>>> You are right. I have had in mind a generational GC that uses 
>>> a
>>> copying collector for the nursery as this is what most
>>> state-of-the-art VM GCs do.
>> These changes are too invasive for the language at this point, 
>> I
>> believe. We need to work with what we have.
>
> I disagree. Code that relies on other semantics would just have 
> to use conservative GC.

Please elaborate on how you would hypothetically change D to 
accustom such changes. I am having trouble imagining such an 
implementation that would not have a considerable impact on D's 
performance.
December 18, 2011
Re: d future or plans for d3
Le 19/12/2011 00:28, Andrei Alexandrescu a écrit :
> I ordered the GC book :o).
> 
> 
> Andrei

Also, at the risk of being redundant...

http://www.scribd.com/doc/26102695/Garbage-Collection-in-JVM

http://www.scribd.com/doc/59150636/C4-Continuously-Concurrent-Compacting-Collector
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home