Professor Eliot Moss:
Thanks. I think that's the risk I should take, if I ever want to make something. I've already tried different ideas, then failed and turned to this one. I can compare it with different algorithms, to see relative gain and loss.
 
DaFENG
Coder
Telecommunication && Network Industry
Gmail:sunspiderX@gmail.com


From: Eliot Moss <moss@cs.umass.edu>
To: "General discussion of Jikes RVM design, implementation, issues, and plans" <jikesrvm-researchers@lists.sourceforge.net>
Sent: Monday, May 21, 2012 7:16 PM
Subject: Re: [rvm-research] metronome gc

On 5/20/2012 10:00 PM, Da Feng wrote:
> 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.

I didn't mention the Bookmarking Collector; but I did
mention Pauseless ...

One of the reasons to choose a concurrent approach is
a desire for smooth operation / short pauses. Otherwise
a *parallel* collector is easier to implement.

But just being *different* does not imply *better*.
A strong paper or piece of research will argue why a
particular approach is better than its competitors,
or at least offer insight as to why an idea that
looked like it might be better turned out not to be.
(A negative result is much harder to publish, though.)
If it is better, the paper should offer insight as
to why it is better and under what conditions one
gets improvement. And, particularly if the improvement
is modest (10% or less), you need careful methodology
to insure that you are not measuring some other
artifact or just "got lucky", that is, that the
improvement is truly due to your new algorithm. This
can be hard to do convincingly.

Best -- EM

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers