Greedy memory handling

monarch_dodra monarchdodra at gmail.com
Wed Sep 11 06:55:52 PDT 2013


On Wednesday, 11 September 2013 at 13:33:23 UTC, Joseph Rushton 
Wakeling wrote:
> On 11/09/13 15:13, monarch_dodra wrote:
>> That's somewhat better, as it would allow the GC to collect my 
>> buffer, if it
>> wants to, but I wouldn't actually know about it afterwards 
>> which leaves me screwed.
>
> Just to clarify, is this buffer meant only for internal use in 
> your function or is it meant to be externally accessed as well?
>  I'd kind of assumed the former.
>
> Either way, isn't it sufficient to have some kind of
>
>     if (buf is null)
>     {
>         // allocate the buffer
>     }
>
> check in place?  The basic model seems right -- at the moment 
> when you need the buffer, you check if it's allocated (and if 
> not, allocate it as needed); you indicate to the GC that it 
> shouldn't collect the memory; you use the buffer; and the 
> moment it's no longer needed, you indicate to the GC that it's 
> collectable again.
>
> It means having to be very careful to check the buffer's 
> allocation status whenever you want to use it, but I think 
> that's an unavoidable consequence of wanting a static variable 
> that can be freed if needed.
>
> The alternative I thought of was something like comparing the 
> size difference between the currently-needed buffer and the 
> last-needed buffer (... or if you want to be over-the-top, 
> compare to a running average:-), and if the current one is 
> sufficiently smaller, free the old one and re-alloc a new one; 
> but that's a bit _too_ greedy in the free-up-memory stakes, I 
> think.

The buffer is meant strictly for internal use. It never escapes 
the function it is used in, which not re-entrant either.

Basically, I'm storing the buffer in a "static ubyte[]", and if 
there isn't enough room for what I'm doing, I simply make it 
grow. No problems there.

The issue I'm trying to solve is "and the moment it's no longer 
needed" part. The function is really just a free function, in a 
library. The user could use it ever only once, or use it very 
repeatedly, I don't know. I particular, the amount of buffer 
needed has a 1:1 correlation with the user's input size. The user 
could repeatedly call me with input in the size of a couple of 
bytes, or just once or twice with input in the megabytes.

I *could* just allocate and forget about it, but I was curious 
about having a mechanism where the buffer would just be 
"potentially collected" between two calls. As a form of 
"failsafe" if it got too greedy, or if the user just hasn't used 
the function in a while.


More information about the Digitalmars-d-learn mailing list