Yes.

std.gc.removeRange(myArray);

As far as I recall.

But, iirc you do have to do this on a full range (e.g., not a sliced array but the whole allocated array.)

-[Unknown]


> Mars wrote:
>> http://www.osnews.com/comment.php?news_id=16526
> 
> RE[2]: Not much of an update
>  > By luzr (2.10) on 2006-11-19 19:44:17 UTC in reply to "RE: Not much of
>  > an update"
>  >>I second that. D is a very nice language with a clear focus. My first  >>impression was that it has the best of Java, the best of C++ and none  >>of they're major weaknesses.
>  >
>  >Adds one major weekness - its memory model is based on conservative GC, >which makes it unpredictable and in reality unusable for some important >applications (like cryptography or any other software that deals with >noise-like data).
> 
> 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.
> 
> Is there a way to tell the garbage collector "don't look for references here" without using malloc and friends?
> 
> This would be for a standard sliceable garbage collected array with any kind of data except references. Something like gc.doNotLookForReferences(myArray) would be nice.

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)

--bb

On Sun, 19 Nov 2006 19:03:18 -0800, Bill Baxter <dnewsgroup@billbaxter.com> 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)
>
> --bb


The GC maybe reliable for what it does, but it's certainly not optimal.  I think Walter has admitted that in the past also.

-JJR

Mike Capp wrote:
>> One issue brought up is that of D "requiring" the
>> use of a GC. What would it take to prove that wrong
>> by making a full blown standard lib that doesn't
>> use a GC, and in fact doesn't have a GC?
>>
>> It would be painful to work with but no more so
>> than in C++. OTOH with scope() and such, it might
>> be easy.
> 
> It's not just a library issue, and in some ways I think it *would* be
> significantly more painful than in C++. D has a lot of innocuous-looking syntax
> that allocates heap memory non-obviously; AA and dynamic array initialization
> syntax, for instance. Without a GC, that's a lot of leaks and/or runtime errors
> waiting to happen.
> 
> I don't think it's an impossible sell, though. It would help to have a -nogc
> compiler switch or syntax attribute that disallowed usage of these constructs. And
> the scope stuff is coming on nicely; if Walter extends it to support RAII member
> data, as he's mentioned a few times, it'd be great.
> 
> The other big issue mentioned in the article comments is that D's GC
> implementation is lacking. It's hard to say whether a language with native
> pointers would really play nice with a copying collector, f'rinstance. Now that

IIRC, Walter has mentioned that he has some ideas for that. Anyhow, I think the restrictions listed in the D GC doc. covers most/all the concerns about pointers and a moving collector:

http://digitalmars.com/d/garbage.html

> Java is GPL it'll be interesting to see whether the JVM's GC implementation can be
> yanked out for use by other languages: it's generational, copying and pretty
> well-tuned.
> 
> There's some other stuff that's been buzzing around in my head about thread-local
> heaps lately, but it's not coherent enough to constitute a suggestion yet.

Georg Wrede wrote:
> BCS wrote:
>> Mars wrote:
>>
>>> http://www.osnews.com/comment.php?news_id=16526
>>
>> One issue brought up is that of D "requiring" the use of a GC.
>> What would it take to prove that wrong by making a full blown standard lib that doesn't use a GC, and in fact doesn't have a GC?
>>
>> It would be painful to work with but no more so than in C++. OTOH with scope() and such, it might be easy.
>>
>> Anyway, just a thought.
> 
> Having such a library would make a huge difference in every C++ vs D discussion! The opposition would have a lot less ammunition against us.

But the whole concern centers around two canards: a) GC is really slow and b) malloc/free offer deterministic performance for real-time appplications.

I actually think that the best defense is dispelling those two myths. a) for D will come in time and b) is just plain not true for general purpose malloc/free implementations on modern operating systems.

On Sun, 19 Nov 2006 19:27:40 -0800, Dave <Dave_member@pathlink.com> wrote:

> Georg Wrede wrote:
>> BCS wrote:
>>> Mars wrote:
>>>
>>>> http://www.osnews.com/comment.php?news_id=16526
>>>
>>> One issue brought up is that of D "requiring" the use of a GC.
>>> What would it take to prove that wrong by making a full blown standard lib that doesn't use a GC, and in fact doesn't have a GC?
>>>
>>> It would be painful to work with but no more so than in C++. OTOH with scope() and such, it might be easy.
>>>
>>> Anyway, just a thought.
>>  Having such a library would make a huge difference in every C++ vs D discussion! The opposition would have a lot less ammunition against us.
>
> But the whole concern centers around two canards: a) GC is really slow and b) malloc/free offer deterministic performance for real-time appplications.
>
> I actually think that the best defense is dispelling those two myths. a) for D will come in time and b) is just plain not true for general purpose malloc/free implementations on modern operating systems.


Good points!

-JJR

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)
> 
> --bb

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. Since a collector that freed all these "ambiguous" roots would eventually free live objects, one must treat these roots as pointers.

The good news is that most data that falls into this category is temporary, such that the region kept alive by the false pointer will be freed on a subsequent collection.

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.

So the solution for your example is to store the data not in a void[] but in a more appropriately typed container, possibly byte[]. Of course the optimal solution depends on your application.

Julio César Carrascal Urquijo wrote:
> 
> Is there a way to tell the garbage collector "don't look for references here" without using malloc and friends?

Not in its current form, but the modifications to allow this are fairly simple.  The compiler can even set the same flag for dynamic arrays containing elements smaller than pointer size.


Sean

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


Sean

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