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

On 07/05/15 17:33, Jorge Branco wrote:
> 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();

There's an implicit assumption here about the object model.

The bits referred to are bits we assume are available within an existing 
word in the header.  The words referred to are additional words that the 
VM is expected to provide.

In Jikes RVM we have 8 bits available in the Status Word in the header, 
and there's a strong assumption elsewhere in MMTk that we always have at 
least 8 bits (see org.mmtk.utility.HeaderByte).

> 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?

This is exactly the kind of use case for adding additional header words.

You won't be able to increase the header bits beyond 8.  This feature is 
more for future opportunities / other VMs that might be able to adapt 
their object model to the requirements of the GC.

> 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].

The Log bit is used in a Generational collector when using Object 
Logging.  This is where the write barrier marks entire objects as having 
references to the nursery, rather than remembering the individual 
pointer that refers to a Nursery object.  This trades the cost of 
scanning the remembered objects during a nursery GC against the benefit 
of being able to remember each object once.

For more details, check the code that calls HeaderByte.markAsLogged and 
associated methods.

> 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!

There are several reasons.

Much of the MMTk allocation fast-path ends up inlined into the method 
that calls it---this (and the optimization opportunities this exposes) 
is how we get the allocation efficiency we do.  Allowing switching GC at 
run-time would mean that allocation done by the VM itself would have to 
do a virtual dispatch, slowing it down considerably.

One of the GC optimizations we do is specialization (discussed in our 
2011 ISMM paper).  This requires compiling specialized versions of the 
scan method at build time---again, while this *could* be done 
dynamically it's no longer clear that this would be a performance win. 
Key to the performance of these specialized methods is that the type of 
the particular TraceLocal object getting called at compile time is 
precise - the compiler can devirtualize the call to trace each object 
that the scan discovers.

There's also the software engineering decision that a particular Plan is 
*the* memory manager (and hence we can use static fields etc).  Under 
this design, if you want to build a Plan that allows you to choose 
between different GC *policies* at runtime, you're free to do so, but 
that would be another Plan in MMTk's codebase.

cheers,
Robin

> 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
>


------------------------------------------------------------------------------
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