manual memory management

[H. S. Teoh]

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