[rvm-research] A couple of questions regarding MMTk and GCs

Jorge Branco <[email protected]>
Newsgroups gmane.comp.java.jikes.rvm.devel
Message-ID <CAMfCbE-CbjaG-KgXsgjC43aGGXMfPymDVQq5v6j=4jCQcdZ7Lw@mail.gmail.com>
Hello all,

I'm (hopefully) in the process of implementing a garbage collector in
jikesrvm, although I'm facing some difficulties.

Well, to start with : I was happy to find that the code looks great :) It's
not every day that one finds such huge and complex code in such a good
state . Its original coders and maintainers have done an awesome job.

After this small detour, let's get down into the gritty details:

1) What's the difference/point in having both a
PlanConstraints.gcHeaderBits() and PlanConstraints.gcHeaderWords()? Isn't
gcHeaderBits() always possible to calculate based on gcHeaderWords() and
vice-versa? From the javadoc, I can read that:

  /** @return The number of header bits that are required. */
  public abstract int gcHeaderBits();

  /** @return The number of header words that are required. */
  public abstract int gcHeaderWords();

Which confuses me a bit. Do those two properties only regard GC related
stuff, or the full object header? The method names seem to indicate the
former while the javadoc the latter. For instance, what I'm looking for at
the moment is to have an extra word put into an object's header (for GC
purposes) so I can put in every object on the heap what's called in [1] a
"log pointer" (so, for a concurrent mark & sweep this would increase the
total object header to 3 words, if I'm not mistaken). I'm assuming that
it's those two properties that I have to tamper with? What other things
should I take into consideration to make such a change?

2) From what I've seen, I infer PlanConstraints.needsLogBitInHeader() is
what in some other circles may be called as the "gc bit" or "mark bit" in
an object's header -- a bit that is either 1 or 0 whether the object has
been marked by a tracing collector or not. Am I right? In particular, it
has nothing to do with the "log pointer" one can read about, for instance,
in [1].

3) From what I've gathered I must choose at compile time which GC to use,
i.e., it simply isn't possible to switch a GC at execution time by
switching jvm parameters to the jikes process. If this is indeed the case,
I'm curious to know the reason!

Thanks!

References:
[1] "An On-the-Fly Mark and Sweep Garbage Collector Based on Sliding Views"
- https://www.cs.purdue.edu/homes/hosking/690M/ms-sliding-views.ps

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y

_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.