Re: [rvm-research] Questions after reading SemiSpace Plan

Hi,

I will try to answer as much as I can.

On 4/08/13 13:44 , ChenHao wrote:
> Hello All,
> I have several questions about the SemiSpace Collector:
> 1.colletionPhase()
> SS, SSCollector & SSMutator all have the"collectionPhase()"method, but 
> they are different.
> Which class and when call these 3 collectionPhase()? The host VM call 
> them??
> How to arrange phases in collectionPhase()? Although they may have 
> same phaseID, but call different methods.
> For example, SSCollector rebinds ss(CopyLocal) to ToSpace at  
> SS.PREPARE, while SSMutator rebinds ss to ToSpace at  SS.RELEASE.
Phases are arranged in Plan class and its descendant classes. Most of 
the phases are defined in Simple.
For each phase, it is explicitly defined who will join this phase, 
namely global (the Plan class, SS in your case), collector or mutator. 
During GC, collector threads (with CollectorContext) will call 
Phase.processPhaseStack() (see StopTheWorldCollector.collect()) and 
eventually call collectionPhase() of participants to perform their own 
collection phase.
> 2.SSTraceLocal.traceObject()
> Which class and when call SSTraceLocal.traceObject()? 
> SSTraceLocal.traceObject() calls the CopySpace.traceObject().
> I recognized that
> SSCollector.collectionPhase(){if(phaseID==SS.CLOSURE){trace.completeTrace();}}, 
>
> this will call the TraceLocal.completeTrace() to finish processing all 
> GC work.
> The methodprocessRoots() ? processRootEdge() ? 
> traceObeject(object,root) ? traceObject(object)
> ? traceObject(VMSpace/ImmortalSpace/...[but no CopySpace],object).
> The method scanObject()?VM.scanning.specializedScanObject() or 
> VM.scanning.scanObject().
> I'm wondering whetherVM.scanning.specializedScanObject() will call 
> SSTraceLocal.traceObject()?
MMTk requires the hosting VM's help for object scanning. Thus 
VM.scanning.scanObject() needs to be implemented by the hosting VM. So 
the actual implementation is in org.jikesrvm.mm.mmtk.Scanning. And they 
eventually calls TraceLocal.traceObject().
> 3.Constraints
> What needs to be written into Constraints?
> I just know numSpecializedScans().
Constraints for each plan inherits from org.mmtk.PlanConstraints, and 
serves as plan-specific constant class.
> 4.CopySpace
> The initialization of CopySpace depends on vmRequest, whether 
> vmRequest.isDiscontiguous() has a effect on collector's performance?
I have to leave this question to someone else.
> 5.Flip
> SS.collectionPhase(){if(phaseID==SS.RELEASE){fromSpace().release();}}
> This method calls CopySpace.release(),make the FromSpace become 
> Non-FromSpace(Does this mean it becomes a ToSpace?).
> But when and where ToSpace becomes FromSpace?
> SS.collectionPhase(){if(phaseID==SS.PREPARE){hi=!hi;}}
> I guess after a collection allocator allocates objects into ToSpace(in 
> last GC)/Nursery untill it's full, trigger a new collction.
> Now SS.PREPARE, flip the Nursery/ToSpace(in last GC) to FromSpace, 
> FromSpace(in last GC) becomes the ToSpace.Am I right?
In prepare phase, the boolean is flipped and two copy spaces are set 
respectively (one as toSpace and the other as fromSpace) in 
SS.collectionPhase()
>
> 6.How to under stand the components of a collector woks together?
> I thinks that's the reason why I feel confused about some questions 
> above. Any suggestions?
Roughly MMTk works like this:
1. Mutators keep allocating (RVMThread is a subclass of a 
org.mmtk.plan.MutatorContext), which involves the allocation fast path 
and slow path.
2. If the allocation slow path fails, which means heap is full (see 
org.mmtk.utility.alloc.Allocator.allocSlowInline() and 
org.mmtk.policy.Space.acquire()), MMTk controller thread 
(org.mmtk.plan.ControllerCollectorContext) is requested to perform a GC. 
Current mutator thread will be blocked.
3. Controller thread blocks the other mutator thread at their next 
yieldpoint.
4. Controller thread wakens the collector workers (descedants of 
org.mmtk.plan.ParallelCollector), and waits until the GC work is done.
5. ParallelCollector.collect() (of each collector worker) calls 
collectionPhase() of its plan, collector and mutator, and does the 
actual GC work. For object scanning, you can look at the code in 
org.jikesrvm.mm.mmtk.Scanning
6. When GC work is done, workers are parked. Controller thread resumes 
mutator threads and goes to sleep. And go back to Step 1.

This might help you read the code and understand how MMTk works.

Regards,
Yi
>
> Thanks for any help.
> Best Wishes.
> Chen Hao
>
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Jikesrvm-researchers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk

_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers