harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM][GC] parallel compaction and wasted virtual space
Date Mon, 30 Oct 2006 13:52:25 GMT
On 10/29/06, Xiao-Feng Li <xiaofeng.li@gmail.com> 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
>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.

> xiaofeng
> On 10/30/06, Weldon Washburn <weldonwjw@gmail.com> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message