read() performance - Linux.too?

[Derek Parnell]

On Tue, 25 Jul 2006 17:18:24 +1200, Regan Heath wrote:

> On Tue, 25 Jul 2006 15:15:24 +1000, Derek Parnell  
> <derek at nomail.afraid.org> wrote:
>> On Mon, 24 Jul 2006 22:02:31 -0700, Unknown W. Brackets wrote:
>>
>>> Actually, I believe it's just:
>>>
>>> import std.gc;
>>>
>>> // ...
>>>
>>> ubyte[] data = new ubyte[1024 * 1024];
>>> std.gc.removeRange(data);
>>>
>>> This tells it, afaik, not to scan the described range for pointers.  It
>>> seems to me entirely possible that the compiler could automatically
>>> generate this code for new ubyte[] and such calls.
>>
>> Yes, but wouldn't that RAM be deallocated only at program end? If you
>> wanted it deallocated earlier you would still have to delete it.
> 
> The range pointed at by the array 'data' shouldn't be scanned, but there  
> is no reason the array reference itself cannot be scanned and therefore  
> collected, right? And if the array reference is collected, the data will  
> be freed, just not scanned for other pointers, right?

Yes that sort of makes sense. So does the parameter stack get scanned after
a function returns but before the calling function takes control again,
because that's where the array reference resides usually. Or is it that
when a 'new' is done, the returned address is added to a list that the GC
uses to free up RAM from? 

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
25/07/2006 3:29:21 PM