In message <[EMAIL PROTECTED]>, Matt Dillon writes:
> This has nothing to do with overcommit in the context it is being
> discussed. In fact, this has nothing to do with OS memory management
> at all -- all garbage collected languages have their own infrastructure
> to determine when memory pressure requires collecting.
I think we were talking about C, and there are reasonable GC implementations
for C... that assume that they can detect an out-of-memory condition because
malloc returns a null pointer.
> First, that's bullshit. Most garbage collection implementations
> require the memory 'size' to be hardwired. Second, that's bullshit
> because any program relying on that sort of operation had damn well
> better have its datasize limit set to something reasonable, or the
> garbage collector is going to run the system out of swap before it
> decides it needs to do a run through.
Fair enough, other circumstances might *also* cause a scan... but the fact
remains that a GC system will want to know when it's out of memory, and
will want some kind of warning other than a segfault.
> You've completely ignored the point that overcommit has nothing whatsoever
> to do with memory pressure. You are assuming that overcommit is some
> sort of magic bullet that will solve the memory pressure handling problem,
> and it is nothing of the sort.
No one has said it solves all the problems. It solves *one specific* problem;
the problem that you don't get *ANY* warning, or *ANY* chance to do anything,
if you actually run out of available memory. Even if it's a transient failure
that will go away in five minutes. Even if all you need to do is an fwrite
and an fclose.
-s
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
