On Friday 01 February 2002 04:53 pm, you wrote:
> Marcel,
>
> Considering that the average user does run multiple apps and that
> therefore both memory and disk space are dynamic resources your
> "recommendations" for the user to first see how much disk space and
> memory is available sound just ridiculous. In the end, your scheme risks
> a hard crash if you do any real work in a real-life environment and
> that's most definitely not my understanding of a stable application.
>
> In fact, I'd go sofar and argue that automatic lazy virtual memory
> management is one of the most stupid ideas that I've ever heard of. If
> the memory subsystem returns you a supposedly valid pointer to a memory
> block you just allocated why should you be unable to use it? If it
> cannot grant the request it can return Null and have the client deal
> with the problem. With automatic lazy VM you have to be aware that at
> _any_ time you access memory you must be able to recover from a memory
> fault. You should also consider that just catching an exception is not
> enough by far - if that happens to you in the midst of trying to write
> to a forwarding block in the middle of full GC you are just screwed.
>
> Requiring the user to "quit and restart" an application in order to get
> some memory back is ... how do I put this ... not exactly close to
> reality. What if you want to run a server app? Would you require
> Comanche users to "quit and restart" just because you had a temporary
> large request?! BFD? Yes, I'd say so.
>
> And your argument that "the system becomes unusable long before" is not
> always true. I can give you very simple examples that will trigger
> almost all of the effects I'm describing _without_ thrashing memory too
> much (if your OS is reasonable efficient at paging). Here's a simple
> one: Start four Squeak's with -memory 512 and in each of them do:
>
> MemoryHog := (1 to: 100) collect:[:x| Form extent: 1024 at 1024 depth: 32].
> MemoryHog := nil.
> Smalltalk garbageCollect.
>
> A non-issue?! Not when you're doing (for example) large image
> manipulation at various levels. I do. BTW, the above can be done simpler
> as
>
> Form extent: 11000 at 11000 depth: 32.
>
> Takes a couple of seconds but _my_ system is perfectly usable. Before,
> during, and after I do this.
>
> So let's just say that I still think there's a huge difference between
> what I was describing and that Mach behavior. That you haven't seen any
> of these problems in about eight years doesn't mean they don't exist -
> all it means is that _YOU_ haven't seen them.
>
> Cheers,
>   - Andreas
>

	Uhm, guys, but isn't the purpose of a Virtual Memory Manager to make 
disparate chunks of ram and swap space APPEAR to be a contiguous chunk of 
memory to the process that inhabits it?

	I mean, part of a process could lie on disk, and part in memory, for all 
it cares, it lives in one contiguous block.

	Now, I know this COULD be bad for GC, because you'll take hits for the 
parts that happen to lie on disk at the given instant. Course, this is true 
for any app. I've had parts of apps load slow because that feature wasn't 
used for a while, and happened to be swapped out because I opened something 
else.

	You can't avoid swapping from GCing large images. You can minimize it. 
This gets in to memory manager tricks and tips.

	There is no way to guarantee all the memory you allocate from Malloc is 
actual ram, and not disk space, if this is what you are asking....

	Daniel