Professor Eliot Moss:

Thanks. I just checked both Metronome and Bookmark, and find that they declined to be concurrent, metronome:"Since our collector is not concurrent, we explicitly control the interleaving of the mutator and the collector.",
bookmark:"The current BC algorithm is not suitable for concurrent garbage collection:". So I still got a little bit difference. Also metronome and bookmark compaction only process internal fragmentation, I need to address the inter-block fragmentation problem. May be their description of compaction is intended to be simple. I've used a cache-aware approach, similar to immix to relocate free cells, and I count objects usage at sweep time, not mark time. All these can be difference.
 
DaFENG
Coder
Telecommunication && Network Industry
Gmail:sunspiderX@gmail.com


From: Eliot Moss <moss@cs.umass.edu>
To: Da Feng <jvfengda@yahoo.com>; "General discussion of Jikes RVM design, implementation, issues, and plans" <jikesrvm-researchers@lists.sourceforge.net>
Sent: Sunday, May 20, 2012 10:20 PM
Subject: Re: [rvm-research] metronome gc

On 5/20/2012 10:15 AM, Da Feng wrote:
> Hi:
> I find that my mark-sweep-defragment gc algorithm looks like metronome, but the material introducing
> metronome is not as complete as compressor. Can anyone help me to check the differences. I have to
> write a research proposal, so I need to compare the differences. I designed my GC for servers, but
> metronome seems to be designed for embedded systems.

Real-time systems is more the term I would use, but
yes, Metronome is about meeting latency guarantees.
You might also look at and compare with Pauseless,
which was designed for a server environment. And,
blowing my/our own horn a bit, it sounds as if you
might benefit from reading parts of The Garbage
Collection Handbook, of which I am a co-author
(that's the disclaimer :-) ) ...

Regards -- Eliot Moss