On 8/15/06, Robin Garner <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Weldon Washburn Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
