harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM][GC] parallel compaction and wasted virtual space
Date Tue, 31 Oct 2006 00:15:08 GMT
On 10/30/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> 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
> 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.

Well I guess no one has the answer. :-)

> 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 <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

View raw message