Alex, you made good point. It is definitely possible to design GC with dynamic heap size, we will need is careful design for both convenience and performance. Besides the points I mentioned previously, performance tradeoff with heap size is yet another a factor. On one hand, the heap size has a minimal to keep all the live objects during the execution; on the other hand, a larger heap size trigers GC less frequently. So sometimes the GC needs to decide if it should increase the heap size or just trigger a collection, assuming the heap size is enough to hold all the live objects.
Yes, to allocate/release blocks when needed is possible. I'd give you more cases that requires careful design. consider a case . For example, if the block is bigger than an OS page in size, even the GC design can perfectly allocate/release its blocks, the system memory is still fragmented. Another case is, GC sometimes needs to align the block to certain size boundary, which also leaves fragments in system space. Yet another case is, if the system memory space is already seriously fragmented, GC may not be able to utilize the remaining vacant space although the sum size of the fragments can be large. Many of these point to OS/JVM interactions finally. I've been looking at this area. :-) Thanks, xiaofeng On 7/30/06, Alex Blewitt <[EMAIL PROTECTED]> wrote:
On 29/07/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote: > Salikh Zakirov wrote: > > Sorry, the first version would lead to integer overflow and the to assertion > > failure. The updated patch should work. It runs Hello on Windows/ia32 with a warning > > about reducing maximum heap size to the virtual address range it could allocate. > > This is done because GC needs to have contiguous address range for the heap, > and allocates virtual address range upfront. It would seem that for an infinite amount of memory, attempting to allocate a contiguous address range for the heap would be a problem. It's also probably why other VMs have the -Xmx option, and attempt to obtain the range all in one go. However, if the GC is generational, why does it need to be contiguous? Why not allocate chunks per generation? Or, for that matter, why can't it be split into pages/blocks of memory? That way, you wouldn't need to attempt to allocate it all up front, but rather you could tack a new page/block onto the end of the memory list. Obviously, there would be special cases (like when allocating a large array that is greater than the page/block size) but all of these problems have been solved by filing systems in the past. I mean, it's not like creating a ZIP file attempts to allocate a contiguous block of 256Mb and then fills it up as files are added. (However, that is pretty much what happens when you create a DMG on Mac OS X ...) Incidentally, a very good book on file system design discusses the Be Filing System (BFS) and it's available at http://www.nobius.org/~dbg/practical-file-system-design.pdf Note that I'm mostly asking these questions in an attempt to find out why it can't be done, and/or how much would need to change to be able to do something like this instead. I can imagine that if there were some kind of page-on-demand memory obtaining, then you wouldn't need a -Xmx parameter (unless you wanted it), and that you'd be able to deal with this kind of DLL-in-the-middle problem that you saw on Windows. Alex. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
