On Wed, Jan 09, 2013 at 06:26:55PM +0100, Rob T wrote: > On Wednesday, 9 January 2013 at 11:24:32 UTC, Jonathan M Davis > wrote: > >Walter wasn't arguing that there wasn't a place for manual memory > >management. He was arguing that you can't guarantee memory safety if > >you're using manual memory management - hence why malloc and free are > >@system. @system code is not memory safe like @safe code is, but it > >still very much has it's place. > > > >- Jonathan M Davis > > You cannot guarantee memory safety with a GC either, depending on > the definition of "memory safety". > > For example, you can still access deallocated memory by mistake,
Are you sure about this? Short of doing pointer arithmetic (which is unsafe by definition), I don't see how you can do this. Where would you get the pointer to that memory from? It has to be stored somewhere, meaning the GC will not deallocate the memory pointed to. > run out of memory due to accumulating persistent pointers left around > by mistake, That is not unsafe. That just means you run out of memory and get an OutOfMemory exception or the OS kills your process. No safety issue there. > or free memory that was not supposed to be freed by mistake. How? The GC, by definition, doesn't free the memory unless nothing is pointing to it. > The GC implementation may fail due to bugs, deallocating live memory > or failing to deallocate inactive memory. You're conflating the theory of GCs and its implementation, which is prone to bugs. By that argument, you might as well say that there is no such thing as memory safety, because implementations are always prone to bugs. Your RAM could catch fire, for example. There's nothing you can do in software to prevent that. That's not a helpful argument, though. The question at hand is, given a GC, which presumably has been thoroughly debugged, does it guarantee memory safety? I think it does, because as long as there's a pointer to the memory left, the GC will not collect it, and so you can't use the pointer to access invalid memory. If there are no more pointers to that memory, then by definition you have nothing to access that memory with. Like I said, you have to get the pointer from *somewhere*. As long as the pointer is somewhere, the GC will find it, and mark the memory as used, so it won't be collected. If there are no pointers left, you also have no way to access that memory anymore. So you can never access invalid memory. It's very straightforward. This memory safety can be broken only if you allow pointer arithmetic and casts to/from pointers. But everyone knows that pointer arithmetic is unsafe by definition; I don't think we're talking about that here. [...] > I also doubt that a "one size fits" all approach to garbage > collection will ever satisfy everyone. Of course not. That's why the game devs on this list have been doing GC-less D programming. :-) But that also means they have to either preallocate everything, or they have to manually manage the memory (with malloc/free or equivalent), which is unsafe, because it's very easy to free some memory while there are still pointers to it left. > What's needed is the ability to both manage memory manually and > automatically (D allows this which is good), but also allow for the > automated methods to be easily replaced (plug-ins come to mind), and > if possible allow sections of code to be managed by completely > different garbage collector implementations that are designed to serve > different purposes (this may or may not be practical to do). [...] I don't know about the practicality of using multiple GCs in a single app, but certainly the ability to choose from a number of alternative GC implementations at compile-time would be very welcome. You could have a GC that has high throughput but introduces intermittent long pauses, and another GC that has lower throughput but has no pauses longer than, say, 0.1 seconds. Then at compile-time you choose one, depending on what you need. An interactive app will choose the second, but a batch processing app will benefit from the first. T -- Why waste time learning, when ignorance is instantaneous? -- Hobbes, from Calvin & Hobbes
