[rvm-research] about the readBarrier

[Peng Du-2]

Hello,

I am currently learning Jikes for my research and have a question on the
read/write barrier, in which I want to do some basic accountings, e.g.
counting heap accesses. It seems referencing anything on the heap, e.g.
fields, in the read barrier will be recursively trapped by the barrier
itself, thus resulting in an infinite loop. Could someone tell me what
the idiomatic way to do memory references in a barrier in Jikes? And is
class field a good medium to carry the counters?

Thanks in advance.







------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

[Steve Blackburn]

Hi Peng Du,

The key concern here is infinite regress---you don't want to call your  
read barrier from within the implementation of your read barrier.

So to solve that problem you need to be clear about:
        a) What your barrier is (ie where it is injected).
        b) What semantics you want your barrier to implement.

As for a), I'm guessing from what you've said that you're talking  
about a getfield barrier for reference types.    If so, you'll need to  
avoid getfields to reference types from within your implementation.    
You'd want to be sure you did not do anything tricky (such as trip a  
write barrier or perform allocation) which cause mutual recursion.

As for b) it sounds like you just want integer (or long) counters.

This should be pretty easy to do.  A naive cut would be just to use  
static longs for the counter/s.   Accessing them does not require any  
getfield.   There are two problems with this:  a) you probably want  
thread-local rather than global counters, and b) you should try to  
make the most of MMTk's rich set of counters if you can.

Using the counters naively will require you to use a getfield on  
reference type, so that's no good.   A simple alternative would be add  
fields to your Mutator into which the barrier accumulates counts.    
Inside the barrier code you have direct access to those fields and  
since they are not reference types you won't have a recursion  
problem.   That should be trivial to do.   You can then print those  
counts out directly if you like.   Alternatively you could move those  
counts into MMTk counts at a safe (non-readbarrier) point, such as in  
the PREPARE phase of the Mutator.  The MMTk counters are output if you  
use the harness mechanism (DaCapo provides a hook for this via -c  
MMTkCallback), or if you ask for the entire execution to be harnessed  
via -X:gc:harnessAll=true.

Hope this helps,

--Steve




On 25/08/2009, at 4:18 AM, Peng Du wrote:

> Hello,
>
> I am currently learning Jikes for my research and have a question on  
> the
> read/write barrier, in which I want to do some basic accountings, e.g.
> counting heap accesses. It seems referencing anything on the heap,  
> e.g.
> fields, in the read barrier will be recursively trapped by the barrier
> itself, thus resulting in an infinite loop. Could someone tell me what
> the idiomatic way to do memory references in a barrier in Jikes? And  
> is
> class field a good medium to carry the counters?
>
> Thanks in advance.
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

[Peng Du-2]

Dr. Blackburn,

Thanks for your detailed answer. It helps a lot. A simple trial shows
that a static counter array works quite well and does not incur any
recursion. I am going to read more on MMTK and Jikes and post back new
questions if any.

Thanks

Peng




On Tue, 2009-08-25 at 09:15 +1000, Steve Blackburn wrote:

> Hi Peng Du,
>
> The key concern here is infinite regress---you don't want to call your  
> read barrier from within the implementation of your read barrier.
>
> So to solve that problem you need to be clear about:
> a) What your barrier is (ie where it is injected).
> b) What semantics you want your barrier to implement.
>
> As for a), I'm guessing from what you've said that you're talking  
> about a getfield barrier for reference types.    If so, you'll need to  
> avoid getfields to reference types from within your implementation.    
> You'd want to be sure you did not do anything tricky (such as trip a  
> write barrier or perform allocation) which cause mutual recursion.
>
> As for b) it sounds like you just want integer (or long) counters.
>
> This should be pretty easy to do.  A naive cut would be just to use  
> static longs for the counter/s.   Accessing them does not require any  
> getfield.   There are two problems with this:  a) you probably want  
> thread-local rather than global counters, and b) you should try to  
> make the most of MMTk's rich set of counters if you can.
>
> Using the counters naively will require you to use a getfield on  
> reference type, so that's no good.   A simple alternative would be add  
> fields to your Mutator into which the barrier accumulates counts.    
> Inside the barrier code you have direct access to those fields and  
> since they are not reference types you won't have a recursion  
> problem.   That should be trivial to do.   You can then print those  
> counts out directly if you like.   Alternatively you could move those  
> counts into MMTk counts at a safe (non-readbarrier) point, such as in  
> the PREPARE phase of the Mutator.  The MMTk counters are output if you  
> use the harness mechanism (DaCapo provides a hook for this via -c  
> MMTkCallback), or if you ask for the entire execution to be harnessed  
> via -X:gc:harnessAll=true.
>
> Hope this helps,
>
> --Steve
>
>
>
>
> On 25/08/2009, at 4:18 AM, Peng Du wrote:
>
> > Hello,
> >
> > I am currently learning Jikes for my research and have a question on  
> > the
> > read/write barrier, in which I want to do some basic accountings, e.g.
> > counting heap accesses. It seems referencing anything on the heap,  
> > e.g.
> > fields, in the read barrier will be recursively trapped by the barrier
> > itself, thus resulting in an infinite loop. Could someone tell me what
> > the idiomatic way to do memory references in a barrier in Jikes? And  
> > is
> > class field a good medium to carry the counters?
> >
> > Thanks in advance.
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> > 30-Day
> > trial. Simplify your report design, integration and deployment - and  
> > focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Jikesrvm-researchers mailing list
> > Jikesrvm-researchers@...
> > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

[Peng Du-2]

Hello, everyone

I created a static array of SynchronizedCounter(s) in the
MutatorContext class, which worked fine. But in the read
and write barriers in the GenMutator class, an counter
update, e.g.

---> counters[4].increment();

resulted in the following error when building boot-image.
Could anyone point me out the problem in the counting code?

Thanks

-----------------------------------------------------------------------------------------------
build-bootimage:
     [echo] Building bootimage. Output redirected to : /home/peng/trunk/jikes/jikesrvm/target/production_ia32-linux/BootImageWriterOutput.txt
     [echo] MMTk properties = /home/peng/trunk/jikes/jikesrvm/build/mmtk/default.properties
     [java] BootImageWriter: compiler arg: O2
     [java] Java Result: 101
     [echo] BootImageCompiler: init (opt compiler)
     [echo] Compiler failure during compilation of < BootstrapCL, Lorg/jikesrvm/classloader/RVMClass; >.resolve ()V
     [echo] java.lang.NullPointerException
     [echo] at org.jikesrvm.compilers.opt.regalloc.LinearScan$ActiveSet.allocate(LinearScan.java:1146)
     [echo] at org.jikesrvm.compilers.opt.regalloc.LinearScan$LinearScanPhase.perform(LinearScan.java:322)
     [echo] at org.jikesrvm.compilers.opt.driver.CompilerPhase.performPhase(CompilerPhase.java:205)
     [echo] at org.jikesrvm.compilers.opt.driver.OptimizationPlanAtomicElement.perform(OptimizationPlanAtomicElement.java:88)
     [echo] at org.jikesrvm.compilers.opt.driver.OptimizationPlanCompositeElement.perform(OptimizationPlanCompositeElement.java:143)
     [echo] at org.jikesrvm.compilers.opt.driver.OptimizationPlanCompositeElement.perform(OptimizationPlanCompositeElement.java:143)
     [echo] at org.jikesrvm.compilers.opt.driver.OptimizationPlanCompositeElement.perform(OptimizationPlanCompositeElement.java:143)
     [echo] at org.jikesrvm.compilers.opt.driver.CompilationPlan.execute(CompilationPlan.java:131)
     [echo] at org.jikesrvm.compilers.opt.driver.OptimizingCompiler.compile(OptimizingCompiler.java:169)
     [echo] at org.jikesrvm.compilers.opt.driver.OptimizingBootImageCompiler.compileMethod(OptimizingBootImageCompiler.java:119)
     [echo] at org.jikesrvm.compilers.common.BootImageCompiler.compile(BootImageCompiler.java:75)
     [echo] at org.jikesrvm.compilers.common.BootImageCompiler.compile(BootImageCompiler.java:80)
     [echo] at org.jikesrvm.classloader.NormalMethod.genCode(NormalMethod.java:180)
     [echo] at org.jikesrvm.classloader.RVMMethod.compile(RVMMethod.java:729)
     [echo] at org.jikesrvm.classloader.RVMMethod.getCurrentEntryCodeArray(RVMMethod.java:713)
     [echo] at org.jikesrvm.classloader.RVMClass.instantiate(RVMClass.java:1441)
     [echo] at org.jikesrvm.tools.bootImageWriter.BootImageWorker.run(BootImageWorker.java:44)
     [echo] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
     [echo] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
     [echo] at java.lang.Thread.run(Thread.java:636)
     [echo] Error compiling method: < BootstrapCL, Lorg/jikesrvm/classloader/RVMClass; >.resolve ()V
     [echo] org.jikesrvm.compilers.opt.OptimizingCompilerException: ERROR produced in module:Compiler
     [echo]     failure during compilation of < BootstrapCL, Lorg/jikesrvm/classloader/RVMClass; >.resolve ()V
     [echo]
     [echo] at org.jikesrvm.compilers.opt.driver.OptimizingCompiler.fail(OptimizingCompiler.java:264)
     [echo] at org.jikesrvm.compilers.opt.driver.OptimizingCompiler.compile(OptimizingCompiler.java:183)
     [echo] at org.jikesrvm.compilers.opt.driver.OptimizingBootImageCompiler.compileMethod(OptimizingBootImageCompiler.java:119)
     [echo] at org.jikesrvm.compilers.common.BootImageCompiler.compile(BootImageCompiler.java:75)
     [echo] at org.jikesrvm.compilers.common.BootImageCompiler.compile(BootImageCompiler.java:80)
     [echo] at org.jikesrvm.classloader.NormalMethod.genCode(NormalMethod.java:180)
     [echo] at org.jikesrvm.classloader.RVMMethod.compile(RVMMethod.java:729)
     [echo] at org.jikesrvm.classloader.RVMMethod.getCurrentEntryCodeArray(RVMMethod.java:713)
     [echo] at org.jikesrvm.classloader.RVMClass.instantiate(RVMClass.java:1441)
     [echo] at org.jikesrvm.tools.bootImageWriter.BootImageWorker.run(BootImageWorker.java:44)
     [echo] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
     [echo] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
     [echo] at java.lang.Thread.run(Thread.java:636)
 
-----------------------------------------------------------------------------------------------




On Mon, 24 Aug 2009 21:47:03 -0500
Peng Du <pdu@...> wrote:

> Dr. Blackburn,
>
> Thanks for your detailed answer. It helps a lot. A simple trial shows
> that a static counter array works quite well and does not incur any
> recursion. I am going to read more on MMTK and Jikes and post back new
> questions if any.
>
> Thanks
>
> Peng
>
>
>
>
> On Tue, 2009-08-25 at 09:15 +1000, Steve Blackburn wrote:
> > Hi Peng Du,
> >
> > The key concern here is infinite regress---you don't want to call
> > your read barrier from within the implementation of your read
> > barrier.
> >
> > So to solve that problem you need to be clear about:
> > a) What your barrier is (ie where it is injected).
> > b) What semantics you want your barrier to implement.
> >
> > As for a), I'm guessing from what you've said that you're talking  
> > about a getfield barrier for reference types.    If so, you'll need
> > to avoid getfields to reference types from within your
> > implementation. You'd want to be sure you did not do anything
> > tricky (such as trip a write barrier or perform allocation) which
> > cause mutual recursion.
> >
> > As for b) it sounds like you just want integer (or long) counters.
> >
> > This should be pretty easy to do.  A naive cut would be just to
> > use static longs for the counter/s.   Accessing them does not
> > require any getfield.   There are two problems with this:  a) you
> > probably want thread-local rather than global counters, and b) you
> > should try to make the most of MMTk's rich set of counters if you
> > can.
> >
> > Using the counters naively will require you to use a getfield on  
> > reference type, so that's no good.   A simple alternative would be
> > add fields to your Mutator into which the barrier accumulates
> > counts. Inside the barrier code you have direct access to those
> > fields and since they are not reference types you won't have a
> > recursion problem.   That should be trivial to do.   You can then
> > print those counts out directly if you like.   Alternatively you
> > could move those counts into MMTk counts at a safe
> > (non-readbarrier) point, such as in the PREPARE phase of the
> > Mutator.  The MMTk counters are output if you use the harness
> > mechanism (DaCapo provides a hook for this via -c MMTkCallback), or
> > if you ask for the entire execution to be harnessed via
> > -X:gc:harnessAll=true.
> >
> > Hope this helps,
> >
> > --Steve
> >
> >
> >
> >
> > On 25/08/2009, at 4:18 AM, Peng Du wrote:
> >
> > > Hello,
> > >
> > > I am currently learning Jikes for my research and have a question
> > > on the
> > > read/write barrier, in which I want to do some basic accountings,
> > > e.g. counting heap accesses. It seems referencing anything on the
> > > heap, e.g.
> > > fields, in the read barrier will be recursively trapped by the
> > > barrier itself, thus resulting in an infinite loop. Could someone
> > > tell me what the idiomatic way to do memory references in a
> > > barrier in Jikes? And is
> > > class field a good medium to carry the counters?
> > >
> > > Thanks in advance.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------------------------
> > > Let Crystal Reports handle the reporting - Free Crystal Reports
> > > 2008 30-Day
> > > trial. Simplify your report design, integration and deployment -
> > > and focus on
> > > what you do best, core application coding. Discover what's new
> > > with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > > _______________________________________________
> > > Jikesrvm-researchers mailing list
> > > Jikesrvm-researchers@...
> > > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
> >
> >
> > ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports
> > 2008 30-Day trial. Simplify your report design, integration and
> > deployment - and focus on what you do best, core application
> > coding. Discover what's new with Crystal Reports now.
> > http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Jikesrvm-researchers mailing list
> > Jikesrvm-researchers@...
> > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day trial. Simplify your report design, integration and deployment
> - and focus on what you do best, core application coding. Discover
> what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

[Eliot Moss]

I may be off base, but did you add your new classes,
and the class for arrays of them (as necessary), to
the list of classes that need to be compiled into
the boot image?

Cheers -- Eliot

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

[Peng Du-2]

Dear Eliot

I didn't add any classes. I've only modified class Plan, GenMutator,
MutatorContext slightly.

The array is allocated in the MutatorContext class:

----------------------------------------------------
    counters = new SynchronizedCounter [numPages];
    for (int i=0; i<numPages; ++i){
      counters [i] = VM.newSynchronizedCounter();
    }
----------------------------------------------------

Thanks



On Thu, 27 Aug 2009 14:40:52 -0400
Eliot Moss <moss@...> wrote:

> I may be off base, but did you add your new classes,
> and the class for arrays of them (as necessary), to
> the list of classes that need to be compiled into
> the boot image?
>
> Cheers -- Eliot
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day trial. Simplify your report design, integration and deployment
> - and focus on what you do best, core application coding. Discover
> what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers