manual memory management

[Rob T]

On Wednesday, 9 January 2013 at 18:46:53 UTC, Walter Bright wrote:
> On 1/9/2013 9:26 AM, Rob T wrote:
>> For example, you can still access deallocated memory by 
>> mistake,
>
> If you're not playing with pointers, then this is a buggy GC.

Yes you are correct. I was thinking of nullable references when I 
made that comment. When you dereference on a nulled reference, I 
suppose that's not really referencing deallocated memory. I'm not 
sure what exactly happens behind the scenes when you dereference 
a null pointer, but obviously bad things happen and it's not 
safe, also it is a memory related problem.

>
>> run out of
>> memory due to accumulating persistent pointers left around by 
>> mistake,
>
> Memory safety does not imply never running out of memory.

I did qualify what I said by mentioning that it depends on the 
definition of memory safety. According to my definition of memory 
safety, a memory leak is still a memory leak no matter how it 
happens. I can however see an alternate definition which is 
likely what you are suggesting, where so long as you are not 
accessing memory that is not allocated, you are memory safe. 
There must be more to it than that, so if you can supply a more 
correct definition, that would be welcome.

>> or free memory that was not supposed to be freed by mistake.
>
> Then it's a buggy GC.

Yes. The point however is that a GC can be buggy, so by having 
one kicking around guarantees nothing unless you can prove that 
the implementation is 100% correct.

I am reminded of the back up system that is less reliable than 
the medium it is supposed to be protecting, or the power backup 
supply that is less reliable than the main power grid.

My guess is that no one knows how good or bad a GC is relative to 
what a manual system can do. The claims are likely the result of 
anecdotal evidence alone. Has anyone actually done a 
scientifically valid study that shows that a GC implementation is 
statistically more reliable than a manual implementation?

Of course I understand that the lack of a scientific study proves 
nothing either way, I'm simply pointing out that we're likely 
making assumptions without any proof to back them up.

>> The GC implementation may
>> fail due to bugs, deallocating live memory or failing to 
>> deallocate inactive
>> memory.
>
> Of course memory safety presumes a correctly implemented GC.

Yes, of course, but this is a bit of a wild card since we 
probably have no proof that any given GC implementation will be 
correct.

>> The only thing a GC can do for you, is free up the programmer 
>> from the tedium of
>> managing memory. It also allows constructs that otherwise 
>> would be very
>> difficult or impractical to implement. The effect can be very 
>> positive, but
>> there are no guarantees of memory safety.
>
> This is incorrect - see above. A bug free GC, and not 
> "cheating" in using it, guarantees memory safety. This is a big 
> deal.

Yes and no. Yes if the definition excludes the ability to "leak 
memory" due to programmer error, meaning allocating but failing 
to deallocate - a GC cannot prevent this, only a programmer can. 
I figure your definition excludes this kind of programmer error, 
and that's OK with me.

I do however wonder about the ability to dereference null 
pointers, specifically pointers that are considered to be 
references. In D references are nullable, and I believe this is 
considered safe.

-rt