January 11, 2013 Re: manual memory management | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 01/08/2013 06:30 AM, H. S. Teoh wrote: > ... > > I don't know if I know them all, but certainly the following are > GC-dependent: > > - Slicing/appending arrays (which includes a number of string > operations), .dup, .idup; Slicing is not GC-dependent. > - Delegates & anything requiring access to local variables after the > containing scope has exited; Yes, but this does not make delegate literals useless without a GC. scope delegate literals do not allocate but instead point directly to the stack. > - Built-in AA's; > - Classes (though I believe it's possible to manually manage memory for > classes via Phobos' emplace), including exceptions (IIRC); Classes are not GC-dependent at all. 'new'-expressions are GC-dependent. (though I think DMD still allows overloading them.) > - std.container (IIRC Andrei was supposed to work on an allocator model > for it so that it's usable without a GC) > > AFAIK, the range-related code in Phobos has been under scrutiny to > contain no hidden allocations (hence the use of structs instead of > classes for various range constructs). So unless there are bugs, > std.range and std.algorithm should be safe to use without involving the > GC. > The choice of structs vs classes is kind of necessary. I do not always want to write 'save' in order to not consume other copies of the range. (InputRangeObject notably gets this wrong, this is why it is not used.) > Static arrays are GC-free, and so are array literals (I *think*) as long > as you don't do any memory-related operation on them like appending or > .dup'ing. Currently, with DMD, array literals always allocate if they are not static. (Even if they are directly assigned to a static array variable!) > So strings should be still somewhat usable, though quite > limited. I don't know if std.format (including writefln & friends) > invoke the GC -- I think they do, under the hood. So writefln may not be > usable, or maybe it's just certain format strings that can't be used, > and if you're careful you may be able to pull it off without touching > the GC. > I think they use output ranges under the hood. The main issue is toString(), which inherently requires GC allocation. > AA literals are NOT safe, though -- anything to do with built-in AA's > will involve the GC. (I have an idea that may make AA literals usable > without runtime allocation -- but CTFE is still somewhat limited right > now so my implementation doesn't quite work yet.) > I think the fact that it is not possible to save away arbitrary data structures at compile time for runtime use is just a limitation of the current implementation. Anyways mutable literals require allocation because of aliasing concerns. > But yeah, it would be nice if the official docs can indicate which > features are GC-dependent. > > > T > |
January 12, 2013 Re: manual memory management | ||||
---|---|---|---|---|
| ||||
Posted in reply to Rob T | On 01/09/2013 08:33 AM, Rob T wrote:
> On Wednesday, 9 January 2013 at 07:23:57 UTC, Mehrdad wrote:
>> On Wednesday, 9 January 2013 at 07:22:51 UTC, deadalnix wrote:
>>> Well, you CAN indeed, create a dumbed down language that is memory
>>> safe and don't require a GC.
>>
>>
>> Yeah, that's 1 of my 2 points.
>>
>>
>> The other one you still ignored: the GC doesn't bring much to the
>> table. (Re C# Java etc.)
>
> There is a point being made here that is perfectly valid. There is a
> form of memory leak that a GC can never catch, such as when when memory
> is allocated and simply never deallocated by mistake due to a persistent
> "in use" pointer that should have been nulled but wasn't.
> ...
This is not entirely accurate. A GC does not necessarily have to assume that every reachable pointer will be accessed again. Every memory leak can be caught by some GC, but no GC catches all.
|
Copyright © 1999-2021 by the D Language Foundation