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] Goals for 2006/2007
Date Thu, 17 Aug 2006 23:35:18 GMT
On 8/17/06, Morozova, Nadezhda <nadezhda.morozova@intel.com> wrote:
> All,
>
> I found some GC requirements description in the OPEN spec [1], section
> 5.3.5 and something inside 6.*. How does those suggestions relate to
> what is being discussed?

Actually section 5.3.5 describes an interface between GC and JVM.
What is being discussed on this thread is the design of the GC itself.

>
> Do you think we can use that doc as the basis and maybe track major
> decisions there? Mail threads tend to drop, and are not always a
> convenient means of finding the final decision for an issue :)

I rather hold a conversation using email.  A spec is not the right
tool for the discussion.  When we have agreement on what we are
building and have some code working, we can think about moving chunks
of the dialog in the spec.  Its still too early.

>
> [1] http://issues.apache.org/jira/browse/HARMONY-459
>
> Best regards,
> Nadya Morozova
>
> -----Original Message-----
> From: Weldon Washburn [mailto:weldonwjw@gmail.com]
> Sent: Monday, August 14, 2006 9:23 PM
> To: harmony-dev@incubator.apache.org
> Subject: [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
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message