On 31/07/06, will pugh <[EMAIL PROTECTED]> wrote:
What does matter is whether you are using more virtual memory than you have physical memory.
I agree completely. But the VM developer (in C) does not know how much memory I have present. Why should it assume 256m? I have more memory than that on my laptop available, and a lot more on my desktop. And the problem with an arbitrary default is that if I want to disable that, I have to supply extra parameters. Don't get me wrong; being able to specify minimum/maximum is a reasonable idea for optimising a VM if you know what to put; but by default, there shouldn't be any arbitrary limitations based on the value of a #define constant ...
My understanding is that one of the important reasons for having a Max on the allocation availble to a VM from the beginning was to make sure the heap never used more than physical memory.
Agreed, but the strategy falls apart when Max << TotalAvailable. When JVMs first started, 256m might have sound like a reasonable max, but these days machines have >> 512m available. Thus, there shouldn't be a Max by default. You can't even do an analysis based on how much memory is currrently free. If I'm running a JVM and there's (say) 400m available, would you pick that? What happens if it was running out of memory, and I closed down some memory hog or IDE to free up some space? Why limit it just to 400m? In fact, can you think of any other system with automatic memory management (Smalltalk, C++ with GC, Python, Ruby, PHP, Basic, C#) that decides on a random upper limit 'to protect the user'? I can't think of a single instance when the default max has been helpful for me.
Zones sound like an interesting strategy, but I'm not sure they help you much with wanting make the default memory option "unlimited". Generational is good at reducing the number of full GCs you do, but does not necassarily eliminate them.
Zones were a completely orthogonal idea; I merely brought it up because they were something that I'd been thinking would be a good idea w.r.t. VMs, and since there were a few people here that were talking about low-level VM issues, thought it would be worth mentioning :-)
The zones strategy you suggest may work well with apps that have a lot of class loaders and allocate somewhat evenly across them, but I think it may cause a lot of overhead. Would your approach be generational? Would you need Write Barriers for both references from other generations as well as other Class Loaders?
I've no idea if it would cause a lot of overhead. It might do. I'd imagine that each zone would have a nursery and mature generation, but possibly share some permanent generation.
If you were to have a Web Application, would you basically need a write barrier for every string you allocate, since the String Class is loaded in a parent class loader? If so, this may cause more overhead than you would want for the stated benefit.
I suspect that if a write barrier was needed, this would quickly kill any of the efficiencies. Perhaps there would be some other optimisations that could avoid such things? Alex. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
