You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/08/14 19:23:05 UTC
[DRLVM][GC] Goals for 2006/2007
All,
There is rough consensus that the immediate goal for Harmony JVM is to
reliably run simple commercial workloads with acceptable performance.
In regards to a garbage collector for a Harmony JVM in 2006 there are
some data points worth noting. 1) A quick survey shows most basic
commercial JVMs implement a generational collector. 2) While the
existing drlvm garbage collector, gcv4, implements some interesting
advanced concepts, it is not currently a generational collector. 3)
The MMTk port to drlvm is not yet finished. Even assuming MMTk's
generational configuration is appropriate, it is still too early to
put this garbage collector on the roadmap for a 2006 Harmony JVM. It
might be worth revisiting in 2007. But it's too far away to debate at
this time.
Given the above data points, the following is a first stab at
requirements for Harmony "GCV5". The intention is to set down some
basic parameters.
1)
Generational Collector with mark/compacting mature object space
2)
Parallel collection, no concurrent collection (Editor's note: parallel
collection is a specific term meaning that during gc collection, most
CPUs in an SMP box are busy collecting garbage. This is fairly
straight forward to build. Concurrent collection is a specific term
meaning that Java application threads make forward progress while
special GC threads are simultaneously collecting. This is hard to
build)
3)
Parallel allocation. (Again, this is very straight forward. Basically
each Java thread gets private chunks of memory to allocate out of.)
4)
Write barriers. A generational collector benefits from write barriers
that detect whenever a pointer to a younger object is written inside
an older object.
5)
For expediency, GCV5 should try to plug into the existing JVM/GC
interface. However, if this interface is broken, we need to jump at
the opportunity to make it right.
6)
The goal is to make this code readable/modifiable/debuggable by non-GC
engineers. The code should read as nothing more than a basic
generational GC. No experimental code should ever be checked into
Harmony GCV5 source base.
7)
Performance goals should be discussed after the initial implementation
is committed.
8)
Object pinning is not required at this time. However, be prepared
that at a later date we might discover pinning is needed to get
acceptable performance from native methods that use JNI.
9)
Supports Java 1.5. This means GCV5 must implement functionality such
as weak/soft/phantom references and finalization.
10)
Though this work will be an investment, it is ultimately necessary for
Harmony to meet medium term goals, eg., being maintainable, passing
TcK successfully, etc. and be a platform for future, more advanced
work, which is a requirement that v4 cannot meet.
Thoughts on the above?
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM][GC] Goals for 2006/2007
Posted by Ivan Volosyuk <iv...@gmail.com>.
On 8/15/06, Robin Garner <ro...@anu.edu.au> wrote:
> Weldon Washburn wrote:
> > All,
> >
> > There is rough consensus that the immediate goal for Harmony JVM is to
> > reliably run simple commercial workloads with acceptable performance.
> > In regards to a garbage collector for a Harmony JVM in 2006 there are
> > some data points worth noting. 1) A quick survey shows most basic
> > commercial JVMs implement a generational collector. 2) While the
> > existing drlvm garbage collector, gcv4, implements some interesting
> > advanced concepts, it is not currently a generational collector. 3)
> > The MMTk port to drlvm is not yet finished. Even assuming MMTk's
> > generational configuration is appropriate, it is still too early to
> > put this garbage collector on the roadmap for a 2006 Harmony JVM. It
> > might be worth revisiting in 2007. But it's too far away to debate at
> > this time.
> >
> > Given the above data points, the following is a first stab at
> > requirements for Harmony "GCV5". The intention is to set down some
> > basic parameters.
> >
> > 1)
> > Generational Collector with mark/compacting mature object space
> Why mark/compact specifically ? The easiest approach would be to add a
> copying nursery 'in front' of the exiting GCV4 mature space, and then
> look at replacing/updating the implementation of the mature space. This
> could be achieved with virtually no change to the mature space collector.
>
> As an aside, best performance with a generational collector also comes
> from an Appel-style nursery, ie the nursery size is essentially
> (heap-mature)/2.
>
> The rest of the worklist seems uncontroversial to me, but I wonder how
> much work it is to implement these vs getting MMTk working.
Good point, it seems that this is a way to go. One thing which bothers
me much is that the code of GCV4 is quite bloated. Some cleaning for
the code might be required before.
--
Regards,
Ivan
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM][GC] Goals for 2006/2007
Posted by Weldon Washburn <we...@gmail.com>.
On 8/15/06, Robin Garner <ro...@anu.edu.au> wrote:
> Weldon Washburn wrote:
> > All,
> >
> > There is rough consensus that the immediate goal for Harmony JVM is to
> > reliably run simple commercial workloads with acceptable performance.
> > In regards to a garbage collector for a Harmony JVM in 2006 there are
> > some data points worth noting. 1) A quick survey shows most basic
> > commercial JVMs implement a generational collector. 2) While the
> > existing drlvm garbage collector, gcv4, implements some interesting
> > advanced concepts, it is not currently a generational collector. 3)
> > The MMTk port to drlvm is not yet finished. Even assuming MMTk's
> > generational configuration is appropriate, it is still too early to
> > put this garbage collector on the roadmap for a 2006 Harmony JVM. It
> > might be worth revisiting in 2007. But it's too far away to debate at
> > this time.
> >
> > Given the above data points, the following is a first stab at
> > requirements for Harmony "GCV5". The intention is to set down some
> > basic parameters.
> >
> > 1)
> > Generational Collector with mark/compacting mature object space
> Why mark/compact specifically ?
The basic reason is to start a conversation on top-level requirements
for Harmony GC in 2006. I picked mark/compact probably because of
recent experience with sliding compaction (GCV4).
> The easiest approach would be to add a
> copying nursery 'in front' of the exiting GCV4 mature space, and then
> look at replacing/updating the implementation of the mature space. This
> could be achieved with virtually no change to the mature space collector.
Excellent point. On an implementation level, whoever develops the gc
can certainly reuse any existing Apache licensed code. In this
thread, I would like to keep the discussion on the top-level goals for
2006/2007. But feel free to start a thread on morphing GCV4.
>
> As an aside, best performance with a generational collector also comes
> from an Appel-style nursery, ie the nursery size is essentially
> (heap-mature)/2.
>
> The rest of the worklist seems uncontroversial to me, but I wonder how
> much work it is to implement these vs getting MMTk working.
To date, it been just me working on porting MMTk to DRLVM. I would
love to have someone join me (hint, hint). Assuming reasonable
Harmony GC performance is needed in 2006, I can't promise the MMTk
port will be done and tuned in time. In addition, there may be
dependencies on other VM components such as JIT inlining, JIT
implementation of "Uninterruptible", etc.
As an aside, MMTk is an excellent framework for investigating GC
algorithms. It has really changed my thinking on how to develop GC
algorithms. I really look forward to seeing it run on Harmony.
>
> cheers
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [DRLVM][GC] Goals for 2006/2007
Posted by Robin Garner <ro...@anu.edu.au>.
Weldon Washburn wrote:
> All,
>
> There is rough consensus that the immediate goal for Harmony JVM is to
> reliably run simple commercial workloads with acceptable performance.
> In regards to a garbage collector for a Harmony JVM in 2006 there are
> some data points worth noting. 1) A quick survey shows most basic
> commercial JVMs implement a generational collector. 2) While the
> existing drlvm garbage collector, gcv4, implements some interesting
> advanced concepts, it is not currently a generational collector. 3)
> The MMTk port to drlvm is not yet finished. Even assuming MMTk's
> generational configuration is appropriate, it is still too early to
> put this garbage collector on the roadmap for a 2006 Harmony JVM. It
> might be worth revisiting in 2007. But it's too far away to debate at
> this time.
>
> Given the above data points, the following is a first stab at
> requirements for Harmony "GCV5". The intention is to set down some
> basic parameters.
>
> 1)
> Generational Collector with mark/compacting mature object space
Why mark/compact specifically ? The easiest approach would be to add a
copying nursery 'in front' of the exiting GCV4 mature space, and then
look at replacing/updating the implementation of the mature space. This
could be achieved with virtually no change to the mature space collector.
As an aside, best performance with a generational collector also comes
from an Appel-style nursery, ie the nursery size is essentially
(heap-mature)/2.
The rest of the worklist seems uncontroversial to me, but I wonder how
much work it is to implement these vs getting MMTk working.
cheers
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org