View mode: basic / threaded / horizontal-split · Log in · Help
December 18, 2011
Re: d future or plans for d3
On 12/19/2011 12:45 AM, Vladimir Panteleev wrote:
> 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.

If you have an union

union X{
    int  x;
    int* y;
}

The compiler would just lay out x and y sequentially instead of at the 
same memory location. Alternatively, it could add a tag to each union.

In case of passing GC memory to C functions, I would prefer to just 
disallow the C code to capture the reference, and to disable GC while 
the C function runs. (disabling and enabling GC is just a matter of 
modifying a counter somewhere, that should not visibly impact 
performance.) If C code was to capture a reference to the memory then it 
would probably take ownership anyway, which would necessitate to 
allocate the memory with malloc even with conservative GC.

I am not sure what to do about void[] though.
December 18, 2011
Re: d future or plans for d3
On Sunday, 18 December 2011 at 23:28:16 UTC, Andrei Alexandrescu 
wrote:
> I'm not sure. I seem to recall discussions with pathological 
> cases when large regions of memory were scanned for no good 
> reason.

We need to factor the frequency of such cases, and their impact. 
Also, a more precise GC isn't the only solution to such problems 
- one alternative would be readily-available tools to diagnose 
memory problems. For example, Diamond (the toolkit I've written 
for D1) can display a graphical memory map with scannable areas 
being highlighted. It also allows you to easily find the pointer 
chain that prevents your object from being collected.

> I ordered the GC book :o).

A lot of GC research seems to be tied to VMs. D is a bit of an 
exception...
December 19, 2011
Re: d future or plans for d3
On Sunday, 18 December 2011 at 23:55:17 UTC, Timon Gehr wrote:
> On 12/19/2011 12:45 AM, Vladimir Panteleev wrote:
>> 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.
>
> If you have an union
>
> union X{
>    int  x;
>    int* y;
> }
>
> The compiler would just lay out x and y sequentially instead of 
> at the same memory location. Alternatively, it could add a tag 
> to each union.
>
> In case of passing GC memory to C functions, I would prefer to 
> just disallow the C code to capture the reference, and to 
> disable GC while the C function runs. (disabling and enabling 
> GC is just a matter of modifying a counter somewhere, that 
> should not visibly impact performance.) If C code was to 
> capture a reference to the memory then it would probably take 
> ownership anyway, which would necessitate to allocate the 
> memory with malloc even with conservative GC.
>
> I am not sure what to do about void[] though.

OK... but what about the "generational GC that uses a copying 
collector for the nursery"?
December 19, 2011
Re: d future or plans for d3
On 12/19/2011 01:00 AM, Vladimir Panteleev wrote:
> On Sunday, 18 December 2011 at 23:55:17 UTC, Timon Gehr wrote:
>> On 12/19/2011 12:45 AM, Vladimir Panteleev wrote:
>>> 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.
>>
>> If you have an union
>>
>> union X{
>> int x;
>> int* y;
>> }
>>
>> The compiler would just lay out x and y sequentially instead of at the
>> same memory location. Alternatively, it could add a tag to each union.
>>
>> In case of passing GC memory to C functions, I would prefer to just
>> disallow the C code to capture the reference, and to disable GC while
>> the C function runs. (disabling and enabling GC is just a matter of
>> modifying a counter somewhere, that should not visibly impact
>> performance.) If C code was to capture a reference to the memory then
>> it would probably take ownership anyway, which would necessitate to
>> allocate the memory with malloc even with conservative GC.
>>
>> I am not sure what to do about void[] though.
>
> OK... but what about the "generational GC that uses a copying collector
> for the nursery"?

I am not sure I get the question. The D specification already allows 
moving GC implementations. What is the issue you are thinking about?
December 19, 2011
Re: d future or plans for d3
On Monday, 19 December 2011 at 00:07:47 UTC, Timon Gehr wrote:
>> OK... but what about the "generational GC that uses a copying 
>> collector
>> for the nursery"?
>
> I am not sure I get the question. The D specification already 
> allows moving GC implementations. What is the issue you are 
> thinking about?

How you would implement one with reasonable performance.
December 19, 2011
Re: d future or plans for d3
On Sunday, 18 December 2011 at 23:19:08 UTC, Adam Wilson wrote:
> 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.

This pretty much already describes the current situation.

This is the interface: 
https://github.com/D-Programming-Language/druntime/blob/master/src/core/memory.d#L19

You can install your own GC as a "proxy" (this is used for 
sharing the heap with shared objects):

https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L33

> 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.

It would probably be more practical to allow one GC to be 
configurable at runtime.

> 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.

I believe there have been several attempts to start a no-GC 
runtime+stdlib (including one of mine), but they never got off 
the ground.
December 19, 2011
Re: d future or plans for d3
> In case of passing GC memory to C functions, I would prefer to just 
> disallow the C code to capture the reference, and to disable GC while 
> the C function runs.

Wouldn't this be a problem with non concurrent GC? If you have multiple threads that spend most of the time in C function calls (for example performing IO), garbage collection would be impossible most of the time. In the extreme case garbage would never be collected.

Couldn't we just require that the programmer keeps a reference to the memory passed to C in a D variable? AFAIK python does it that way, but
I don't use python enough to know if it causes serious problems there.
December 19, 2011
Re: d future or plans for d3
On Sun, 18 Dec 2011 15:55:18 -0800, Vladimir Panteleev  
<vladimir@thecybershadow.net> wrote:

> On Sunday, 18 December 2011 at 23:28:16 UTC, Andrei Alexandrescu wrote:
>> I'm not sure. I seem to recall discussions with pathological cases when  
>> large regions of memory were scanned for no good reason.
>
> We need to factor the frequency of such cases, and their impact. Also, a  
> more precise GC isn't the only solution to such problems - one  
> alternative would be readily-available tools to diagnose memory  
> problems. For example, Diamond (the toolkit I've written for D1) can  
> display a graphical memory map with scannable areas being highlighted.  
> It also allows you to easily find the pointer chain that prevents your  
> object from being collected.
>
>> I ordered the GC book :o).
>
> A lot of GC research seems to be tied to VMs. D is a bit of an  
> exception...

Well, maybe we can do the research then, I love research projects myself  
and D would be a good vehicle to display the viability of native GC's,  
especially if we had different implementations to experiment with. Just  
because we aren't a university doesn't mean we can't do research. It seems  
to me that no one else is interested...

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
December 19, 2011
Re: d future or plans for d3
I think there is no need in language changes. Everythink can be 
implemented via library.

What is needed:
 - base agent class
 - base behaviors
 - runtime that provide ability to run independent agents even in 
single-thread mode. Number of agents can be greater then number of 
treads. so scheduler is needed.
 - communication platform to delver messages between agents with 
possibility of broadcasting, multicasting, unicasting (normal).
 - service discovery mechanism allowing to register/deregister agents 
and query for agents with specific roles.

I will prepare more detail answer to the weekend when i get free.

As for applications, i see embedded market: communicating with each 
other phones via bluetooth/wi-fi/GSM/CDMA, robotics and others. At 
least it my hopes.

On 2011-12-18 22:23:28 +0000, Andrei Alexandrescu said:

> On 12/18/11 3:07 PM, Timon Gehr wrote:
>> On 12/18/2011 11:51 AM, Ruslan Mullakhmetov wrote:
>>> On 2011-12-18 00:56:33 +0000, Timon Gehr said:
>>> 
>>>> C++11 does not change the relation between D and C++ a lot. Why do you
>>>> think it does?
>>> 
>>> Because it incorporates many features D declared to be unique to it
>> 
>> It does not, except for the most trivial stuff.
> 
> I think it's best to not derail the argument into a D vs. C++ thing. 
> Ruslan, what language and what library features do you envision should 
> be added, and what would be their most likely applications?
> 
> 
> Thanks,
> 
> Andrei


-- 
BR, Ruslan Mullakhmetov
December 19, 2011
Re: d future or plans for d3
On Monday, 19 December 2011 at 07:11:10 UTC, Adam Wilson wrote:
> It seems to me that no one else is interested...

Not true :)
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home