On Wed, 8 Dec 1999, Mark Hattarki wrote:
> A memory location in a program's address space can be thought of as having
> two states: allocated, and free. I do not claim that you should never be
> able to access an address again, just never be able to access it when
> it's in the "free" state. This is clearly not garbage collection. In fact,
> it's the opposite. I think the memory should be free'd when I call free().
The memory is set aside for reuse, hence freed. That is all it
does. As long as this chunk exists on a page of memory that is allocated,
you can still access it without an exception. Nothing is going to change
this. The virtual memory system allocates pages of memory, not words or
bytes.
> With garbage collection, there is no concept of "free".
Only from the user's perspective. It's still all happening. How do
you suppose the garbage collector works?
> The VM can still do this without a performance hit by doing things like
> seting the one of the status bits (like invalid, readonly, dirty or
> combination thereof) and coding the exception handler to catch the illegal
> dereference, just as it would for a virtual address for a page that have
> not been created yet. So, the claim that this improves performance doesn't
> seem to be valid.
And what do you propose we do, have status bits for every word in
memory? The VM's smallest unit it deals with is pages. This needs to be
(quite) larger than the machine word size or nothing can reasonably get
done.
If you need to debug a broken program, there are libraries that will
get you the behavior you are after. But free will only just set space
aside for reuse, and that's it. End of story. What would you have it do
on a OS without virtual memory in an un-protected mode?
Adam
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]
