OSNews article about C++09 degenerates into C++ vs. D discussion

[Dave]

Sean Kelly wrote:
> Kyle Furlong wrote:
>> Bill Baxter wrote:
>>> Julio César Carrascal Urquijo wrote:
>>>> Mars wrote:
>>>>> http://www.osnews.com/comment.php?news_id=16526
>>>>
>>>> This is one thing that bothers me with the current GC. If you store 
>>>> data with a lot of entropy in an array (Sound, encrypted data, 
>>>> sensor data, etc...) you start to experience memory leaks because 
>>>> the GC starts to see the data as references to other objects.
>>>
>>> This is the kind of comment that scares me.
>>> How does one reconcile this with Walter's comment "The GC has been 
>>> pretty heavily tested. It's 6 years old, and it's stood up extremely 
>>> well."
>>>   --(digitalmars.com digitalmars.D:43916)
>>
>> The problem is that if the data isn't typed, the GC cannot say 
>> absolutely that the data is not pointers into the GC allocated space.
> 
> See my other post.  So long as the user doesn't try to pack pointers 
> into a byte array or something similar, simply using element size can 
> rule out a significant portion of GCed memory.  At the very least, char 
> strings would be ignored.
> 
>> Now in the case of arrays, I think that probably the current collector 
>> is being far too conservative. Since each array is typed, with the 
>> exception of void[], the GC should differentiate between, for example, 
>> a byte[] and a Class[] or void*[] and treat them appropriately.
> 
> The type isn't currently available in the compiler runtime or GC code, 

The TypeInfo is passed in for AA's (aaA.d), so maybe it's a smaller step than we think?

Take your idea of how to skip scanning roots in gcx.d, and add to that TypeInfo for the API in gc.d 
and it may be readily do-able.

> but element size is.  Passing in a TypeInfo object for allocations may 
> be a bit more specific, but I'm not sure the additional complexity would 
> be worthwhile.  I suppose it depends on the application.
> 

Right now I think a different allocation routine is called for byte[] vs. char[] anyway so maybe for 
strings it could be done as-is?

> 
> Sean