Our HeapBlocks strategy is wasteful and the duplication of information between it and the region list makes certain operations difficult. This bug is meant to serve as a list of requirements for a new implementation. Initial list: 1) must use less space 2) kBlockSize and vm page size can be different (limited only to powers of two?) 3) new impl must do more to avoid fragmentation, ie have a smarter/more flexible free block selection mechanism that's does the best thing given the capablilities of the underlying OS and the host's requirements.

Also see bug #520080 (regarding requirement 2 above). I'd settle for the case where the VM block size is an integral multiple of the GCHeap block size. Also see bug #445782 (allowing the use of GCHeap blocks that are not 4KB). I'm not sure that's a requirement because I suspect we won't encounter VM block sizes that are not a multiple of 4KB, but I don't know that for a fact, and we should survey. The 4K limit is pretty heavily ingrained in constants throughout the code. Regarding requirement 3, this looks like an abstraction between GCHeap and the underlying VM subsystem, and some sort of compile-time or run-time capability communication between the two. That sounds exactly right, the lack of a clear abstraction layer here has bugged me for some time.

Also see bug #445780 for related 64-bit issues.