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

On 05/08/13 15:57, Yi Lin wrote:
> 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.

Just to give a little more background, all of MMTk's collectors are
parallel collectors, meaning that there are potentially more than one
collector thread, even during a stop-the-world collection when the
mutator threads are paused. As in any parallel computations, some steps
must only be done by one thread. These steps are done in
Plan.collectionPhase and its sub-classes. All work done in
CollectorContext.collectionPhase is run in parallel by all collector
threads. Work done in MutatorContext.collectionPhase is also done in
parallel by the collector threads, but on behalf of the mutator threads
- the collectors divide the mutator threads among themselves and execute
in parallel.

>> 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.
The PlanConstraints object contains constants that are required before
the static initializers of the Plan class is run. The two classes are
separate in order to break a circular dependency between the virtual
machine and MMTk.
>> 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.
Each space determines the behaviour of a portion of the available
virtual memory. The vmrequest passed to the space constructor tells the
space how to allocate its memory. The only space that is contiguous in
MMTk (that I recall) is the nursery in the generational collectors. This
is so that the write barrier can do a simple address comparison to
determine whether a pointer points from the mature space to the nursery.

I don't believe there is a measurable performance impact from having
SemiSpace's spaces discontigous or contiguous, but if you want to prove
this to yourself it is a very simple change. (And if there is a
difference I'd be interested to know :)
>> 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.
Also try http://docs.codehaus.org/display/RVM/Anatomy+of+a+Garbage+Collector
>
> 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


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