Re: [rvm-research] Scheduling a new Garbage Collection Phase

On 10/07/13 05:39, Nathan Ricci wrote:
> Robin,
>
>        Ah, I get it, so it schedules it after _every_ CLOSURE. That my
> problem; what I really want to do is schedule it after all the CLOSURE
> phases are complete, and all reachable objects are marked. So I think
> I want to schedule after refTypeClosurePhase?
For MarkSweep that sounds right.  More generally, before
completeClosurePhase would probably be correct.

cheers
>
>       --Nathan
>
>           
>
>
> On Mon, Jul 8, 2013 at 8:58 PM, Robin Garner <[email protected]
> <mailto:[email protected]>> wrote:
>
>     On 09/07/13 09:48, Nathan Ricci wrote:
>     >     I'm implementing a garbage collector, called (for now) the
>     > "Control Collector". I've based it on the mark sweep collector, and
>     > the classes are called "GCControl", GCControlCollector, etc.
>     >
>     >     As part of this, I'm trying to add a new collection phase, and I
>     > want to divide some of the work between multiple threads. I seem to
>     > have misunderstood how to do this, however, since in the
>     > GCControlCollector#collectionPhase, I see the same worker ordinal
>     > enter the new phase multiple times in a garbage collection.
>     >
>     >      Do I even have the right idea? Is it the case that in a
>     > Collector, I should only see a given phaseID once per worker ordinal
>     > (as returned by ParallelCollector#parallelWorkerOrdinal()), and the
>     > worker ordinals have a one-to-one correspondence to threads?
>     You have the right idea - this is the intention.
>
>     Bear in mind that the phase CLOSURE is invoked 3 times in a Simple
>     collection, so you should see your control closure invoked 3 times per
>     GC thread.
>
>     What do you see at GC verbosity level 7 with 1 GC thread ?  Two
>     threads ?
>
>     The logic for scheduling phases is in org.mmtk.plan.Phase - it
>     might be
>     helpful to write a pretty-printer for complex phases so that you can
>     statically check the resulting structure after your modification.
>      Some
>     if the login in the Phase class is pretty byzantine, but
>     processPhaseStack is where most of it happens, and this is fairly
>     straightforward.
>
>     Hope this helps,
>     Robin
>     >
>     >      Some code is below. Thanks for any help.
>     >
>     >            --Nathan Ricci
>     >               Tufts University
>     >
>     > I create and schedule the phase in the plan:
>     >
>     > public class GCControl extends MS {
>     > ...
>     >   public static final short CONTROL_CLOSURE =
>     > Phase.createSimple("GCControl.control_closure");
>     >   protected static final short controlClosurePhase =
>     > Phase.createComplex("GCControl.control_closure_complex",
>     >
>     >     null,
>     >
>     >     Phase.scheduleGlobal(CONTROL_CLOSURE),
>     >
>     >     Phase.scheduleCollector(CONTROL_CLOSURE));
>     >
>     > public GCControl() {
>     >     super();
>     >   this.insertPhaseAfter(Phase.scheduleCollector(PREPARE),
>     >    i                         Phase.scheduleComplex(controlPhase));
>     >
>     >     this.insertPhaseAfter(Phase.scheduleCollector(CLOSURE),
>     > Phase.scheduleComplex(controlClosurePhase));
>     >
>     >        ...
>     > }
>     >
>     > Here is the collectionPhase method from the GCControlCollector:
>     >
>     > public void collectionPhase(short phaseId, boolean primary) {
>     >
>     >  if (phaseId == GCControl.CONTROL_CLOSURE) {
>     >    Log.write("GCControlCollector: collectionPhase: CONTROL_CLOSURE
>     > phase: ordinal ");
>     >    Log.write(parallelWorkerOrdinal());
>     >   ...
>     >    return;
>     >  }
>     >   ...
>     >  super.collectionPhase(phaseId, primary);
>     >   }
>     >
>     >
>     > I end up seeing from those log messages that the CONTROL_CLOSURE
>     phase
>     > comes up multiple times with the same worker ordinal, even within a
>     > garbage collection.
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > See everything from the browser to the database with AppDynamics
>     > Get end-to-end visibility with application monitoring from
>     AppDynamics
>     > Isolate bottlenecks and diagnose root cause in seconds.
>     > Start your free trial of AppDynamics Pro today!
>     >
>     http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>     >
>     >
>     > _______________________________________________
>     > Jikesrvm-researchers mailing list
>     > [email protected]
>     <mailto:[email protected]>
>     > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Jikesrvm-researchers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk