On 10/29/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Weldon, the problem is, there is no well-established parallel compaction algorithms. So far the best known work are 1. SUN's work; 2. IBM's work and 3. Compressor. No one knows which one is the best for different workloads. We have to identify one algorithm for implementation, and at the moment Compressor looks to be the right choice, or we write more than one compactors.
Let me ask a different question. At the beginning of the email chain you said:
If we have 1GB physical memory, the JVM is ok for Compressor because the virtual space is large enough to wast half; but if the phsical memory is >2GB, Compressor may have a problem in 32bit machine: some of phsical mapped space might be wasted.
Perhaps you mean to say that with the Compressor algorithm, the JVM's heap is unable to grow beyond 2GB of virtual space. The reason is because Compressor double maps physical memory and thus can not grow beyond one half of the virtual address space. A 2GB Java heap can certainly run on 512MB of physical memory. The result will be unacceptable paging. However, even if a machine contains 4GB of physical memory, the Compressor still can not take advantage of anything above 2GB of physical memory. One question to ask is if restricting the size of the heap to less than 2GC will meet the requirements for Harmony VM in the next 6 months or so. If the answer is no, an additional algorithm will need to be implemented. Also, the Comressor algorithm is only recently published. Given that the focus of Harmony is production quality JVM, there is a risk when implementing any algorithm that is yet unproven in a production environment. Thanks,
xiaofeng On 10/30/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > Since the Compressor algorithm was published only this year, perhaps it > makes sense to consider it experimental. Perhaps make it a compile time > switch so that that folks focused on production quality VM don't trip on > it. Even assuming the implementation of the Compressor algorithm is bug > free, there may be unforeseen performance problems that surface with > different workloads. > -- Weldon Washburn Intel Enterprise Solutions Software Division
