[rvm-research] Call Magic in MMTk

[Peng Du-2]

Hello,

I have a newbie question. I have wrote some code in MMTk
(org.mmtk.utility) calling methods of the
org.jikesrvm.runtime.Magic class.
The compiler complained:

------
package org.jikesrvm.runtime does not exist
------

I know MMTk is supposed to be generic and separated from Jikes. But
I do need to access raw memory in the MMTk code. How can I achieve
this?

Thanks


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

[Colin(Du Li)]

I believe it's class path problem.
You may need modify the build.xml file, and include that org.jikesrvm.runtime class or jar file when compile MMTk.
Hope it helps.

Du Li (Colin)

Peng Du-2 wrote:

Hello,

I have a newbie question. I have wrote some code in MMTk
(org.mmtk.utility) calling methods of the
org.jikesrvm.runtime.Magic class.
The compiler complained:

------
package org.jikesrvm.runtime does not exist
------

I know MMTk is supposed to be generic and separated from Jikes. But
I do need to access raw memory in the MMTk code. How can I achieve
this?

Thanks


------------------------------------------------------------------------------
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
[e-mail]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

[lltong]

Dear Peng,

runtime is created during running time, and may be unavailable while you
are calling them.
If you want to access the raw memory, examine the codes written in C.

Peng Du wrote:

> Hello,
>
> I have a newbie question. I have wrote some code in MMTk
> (org.mmtk.utility) calling methods of the
> org.jikesrvm.runtime.Magic class.
> The compiler complained:
>
> ------
> package org.jikesrvm.runtime does not exist
> ------
>
> I know MMTk is supposed to be generic and separated from Jikes. But
> I do need to access raw memory in the MMTk code. How can I achieve
> this?
>
> Thanks
>
>
> ------------------------------------------------------------------------------
> 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
>  

--
Regards,
Liangliang Tong


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

[Robin Garner]

It's not a class path problem, it's a fundamental design decision for MMTk.

MMTk uses the org.vmmagic API to access raw memory.  The 'Magic' class
is part of JikesRVM, and so shouldn't be called directly from within MMTk.

Methods such as Address.store(), Address.loadInt() etc are what you are
probably after.

If you need some other method that is part of JikesRVM, you need to
extend the MMTk VM Interface, ie the classes in the org.mmtk.vm class,
and their corresponding implementations on the VM side of the fence (the
org.jikesrvm.mm.mmtk package in the directory MMTk/ext/vm/jikesrvm).

Regards,
Robin

Colin(Du Li) wrote:

> I believe it's class path problem.
> You may need modify the build.xml file, and include that
> org.jikesrvm.runtime class or jar file when compile MMTk.
> Hope it helps.
>
> Du Li (Colin)
>
> Peng Du-2 wrote:
>  
>> Hello,
>>
>> I have a newbie question. I have wrote some code in MMTk
>> (org.mmtk.utility) calling methods of the
>> org.jikesrvm.runtime.Magic class.
>> The compiler complained:
>>
>> ------
>> package org.jikesrvm.runtime does not exist
>> ------
>>
>> I know MMTk is supposed to be generic and separated from Jikes. But
>> I do need to access raw memory in the MMTk code. How can I achieve
>> this?
>>
>> Thanks
>>
>>
>> ------------------------------------------------------------------------------
>> 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]

Thanks for all the responses.

I sort of figured out the mechanism between MMTK and Jikes and have
done the extension as Robin said.

However, I can only managed to build a baseline version, which failed
to run with the error:

sp (0x57fb9980)too far below stackLimit ((nil))to recover

I couldn't build an optimizing version due to the following compilation
error:

----------------------------

build-bootimage:
     [echo] Building bootimage. Output redirected to : /home/peng/trunk/jikes/jikesrvm_new/target/FastAdaptiveGenMS_ia32-linux/BootImageWriterOutput.txt
     [echo] MMTk properties = /home/peng/trunk/jikes/jikesrvm_new/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)

----------------------------

Does anyone know what would be the reason for the stack error (baseline)
and compilation error (opt)?


Thanks in advance.




On Mon, 31 Aug 2009 11:02:44 +1000
Robin Garner <robin.garner@...> wrote:

> It's not a class path problem, it's a fundamental design decision for
> MMTk.
>
> MMTk uses the org.vmmagic API to access raw memory.  The 'Magic'
> class is part of JikesRVM, and so shouldn't be called directly from
> within MMTk.
>
> Methods such as Address.store(), Address.loadInt() etc are what you
> are probably after.
>
> If you need some other method that is part of JikesRVM, you need to
> extend the MMTk VM Interface, ie the classes in the org.mmtk.vm
> class, and their corresponding implementations on the VM side of the
> fence (the org.jikesrvm.mm.mmtk package in the directory
> MMTk/ext/vm/jikesrvm).
>
> Regards,
> Robin
>
> Colin(Du Li) wrote:
> > I believe it's class path problem.
> > You may need modify the build.xml file, and include that
> > org.jikesrvm.runtime class or jar file when compile MMTk.
> > Hope it helps.
> >
> > Du Li (Colin)
> >
> > Peng Du-2 wrote:
> >  
> >> Hello,
> >>
> >> I have a newbie question. I have wrote some code in MMTk
> >> (org.mmtk.utility) calling methods of the
> >> org.jikesrvm.runtime.Magic class.
> >> The compiler complained:
> >>
> >> ------
> >> package org.jikesrvm.runtime does not exist
> >> ------
> >>
> >> I know MMTk is supposed to be generic and separated from Jikes.
> >> But I do need to access raw memory in the MMTk code. How can I
> >> achieve this?
> >>
> >> Thanks
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> 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

[Robin Garner]

What exactly have you changed ?  What have you changed since your last
successful build ?

Peng Du wrote:

> Thanks for all the responses.
>
> I sort of figured out the mechanism between MMTK and Jikes and have
> done the extension as Robin said.
>
> However, I can only managed to build a baseline version, which failed
> to run with the error:
>
> sp (0x57fb9980)too far below stackLimit ((nil))to recover
>
> I couldn't build an optimizing version due to the following compilation
> error:
>
> ----------------------------
>
> build-bootimage:
>      [echo] Building bootimage. Output redirected to : /home/peng/trunk/jikes/jikesrvm_new/target/FastAdaptiveGenMS_ia32-linux/BootImageWriterOutput.txt
>      [echo] MMTk properties = /home/peng/trunk/jikes/jikesrvm_new/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)
>
> ----------------------------
>
> Does anyone know what would be the reason for the stack error (baseline)
> and compilation error (opt)?
>
>
> 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

[Peng Du-2]

Dear Robin,

I added a class modeling an array of counters (CounterArray, similar to
an array of SynchronizedCounter) in the package org.jikesrvm.mm.mmtk
extending the abstract CounterArray interface defined in package
org.mmtk.vm. The class is allocated on RawPageSpace and accessed by
Magic.prepareInt and Magic.attempInt. Then added methods in the two
factory classes for its creation. A CounterArray is defined as a
attribute in class org.mmtk.vm.VM. Then, at Plan.fullyBooted,
the counter is allocated via VM. In the read/write barriers of
GenMutator, one of the counter, say #4, is incremented. In
Plan.notifyExit, the counters are written to log.

I have tried BaseBaseGenMS and FastAdaptiveGenMS configurations. The
base version yielded the stack error and the fast version didn't
compile with the boot-image creation error.

Could you point me out the problem in the implementation?

Thanks






On Mon, 31 Aug 2009 15:36:21 +1000
Robin Garner <robin.garner@...> wrote:

> What exactly have you changed ?  What have you changed since your
> last successful build ?
>
> Peng Du wrote:
> > Thanks for all the responses.
> >
> > I sort of figured out the mechanism between MMTK and Jikes and have
> > done the extension as Robin said.
> >
> > However, I can only managed to build a baseline version, which
> > failed to run with the error:
> >
> > sp (0x57fb9980)too far below stackLimit ((nil))to recover
> >
> > I couldn't build an optimizing version due to the following
> > compilation error:
> >
> > ----------------------------
> >
> > build-bootimage:
> >      [echo] Building bootimage. Output redirected
> > to : /home/peng/trunk/jikes/jikesrvm_new/target/FastAdaptiveGenMS_ia32-linux/BootImageWriterOutput.txt
> > [echo] MMTk properties
> > = /home/peng/trunk/jikes/jikesrvm_new/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)
> >
> > ----------------------------
> >
> > Does anyone know what would be the reason for the stack error
> > (baseline) and compilation error (opt)?
> >
> >
> > 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]

Hello, everyone

The error/Exception was caused by reference-before-allocation to the
counters. I wasn't aware that the read/write barrrier can be triggered
even before Plan.fullyBooted(). Since these heap accesses are not
caused by application, they are discarded and only those after
fullyBooted() are counted, when the counters have been properly
allocated. Now the error is gone and everything works well.

Thank you all!



On Mon, 31 Aug 2009 10:18:41 -0500
Peng Du <pdu@...> wrote:

> Dear Robin,
>
> I added a class modeling an array of counters (CounterArray, similar
> to an array of SynchronizedCounter) in the package
> org.jikesrvm.mm.mmtk extending the abstract CounterArray interface
> defined in package org.mmtk.vm. The class is allocated on
> RawPageSpace and accessed by Magic.prepareInt and Magic.attempInt.
> Then added methods in the two factory classes for its creation. A
> CounterArray is defined as a attribute in class org.mmtk.vm.VM. Then,
> at Plan.fullyBooted, the counter is allocated via VM. In the
> read/write barriers of GenMutator, one of the counter, say #4, is
> incremented. In Plan.notifyExit, the counters are written to log.
>
> I have tried BaseBaseGenMS and FastAdaptiveGenMS configurations. The
> base version yielded the stack error and the fast version didn't
> compile with the boot-image creation error.
>
> Could you point me out the problem in the implementation?
>
> Thanks
>
>
>
>
>
>
> On Mon, 31 Aug 2009 15:36:21 +1000
> Robin Garner <robin.garner@...> wrote:
>
> > What exactly have you changed ?  What have you changed since your
> > last successful build ?
> >
> > Peng Du wrote:
> > > Thanks for all the responses.
> > >
> > > I sort of figured out the mechanism between MMTK and Jikes and
> > > have done the extension as Robin said.
> > >
> > > However, I can only managed to build a baseline version, which
> > > failed to run with the error:
> > >
> > > sp (0x57fb9980)too far below stackLimit ((nil))to recover
> > >
> > > I couldn't build an optimizing version due to the following
> > > compilation error:
> > >
> > > ----------------------------
> > >
> > > build-bootimage:
> > >      [echo] Building bootimage. Output redirected
> > > to : /home/peng/trunk/jikes/jikesrvm_new/target/FastAdaptiveGenMS_ia32-linux/BootImageWriterOutput.txt
> > > [echo] MMTk properties
> > > = /home/peng/trunk/jikes/jikesrvm_new/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)
> > >
> > > ----------------------------
> > >
> > > Does anyone know what would be the reason for the stack error
> > > (baseline) and compilation error (opt)?
> > >
> > >
> > > 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 have been looking for the class/object in either MMTk or Jikes that
describes the layout of the object heap with no luck. The classes I
have examined include: VM, Plan, Space, Memory, MemoryManager, and
HeapGrowthManager.

It appeared to me the HEAP_START, HEAP_END, AVAILABLE_START, and
AVAILABLE_END in class VM are what I was looking for. However,
these numbers seem to be never changed regardless of what -Xms and
-Xmx are. Here is a printout from Space.printVMMap (GenMS):

===================================================  
Key: (I)mmortal (N)onmoving (D)iscontiguous (E)xtent (F)raction
     HEAP_START 0x57000000
AVAILABLE_START 0x5c800000
       boot IN  0x57000000->0x66ffffff E 0x10000000
   immortal IND []
       meta  ND [0x68000000->0x693fffff, 0x67400000->0x677fffff]
        los  ND [0x67c00000->0x67ffffff]
     sanity  ND []
 non-moving  ND [0x67000000->0x673fffff]
    sm-code  ND [0x67800000->0x67bfffff]
    lg-code  ND []
    nursery     0x95c00000->0x9fffffff F 0.15
         ms  ND []
  AVAILABLE_END 0xa0000000
       HEAP_END 0xa0000000
===================================================  

What I am asking is:

1) Why are the those numbers fixed despite -Xms and -Xmx?
2) where can I obtain the precise and accurate information on the
layout of the heap (extent and boundaries of each space)?

Thanks




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

[Daniel Frampton]

1) Why are the those numbers fixed despite -Xms and -Xmx?

This is the virtual address range of the heap. Other mechanisms are responsible for ensuring that the heap size is not exceeded. The accounting for this is achieved in the Plan classes in methods like getPagesAvail, getTotalPages, etc. and periodically checked in Plan.poll() as memory is allocated.

 

2) where can I obtain the precise and accurate information on the
layout of the heap (extent and boundaries of each space)?

 

org.mmtk.utility.heap.Map contains a mapping of 4MB chunks of the virtual address space to the individual spaces (e.g, nursery, mature). This can be done statically (e.g., the nursery is currently the top 15% of virtual address space, but this may change) or dynamically, where spaces are allocated 4MB chunks as required. This Map data is used for printVMMap.

 

Cheers,

Daniel.

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

In MMTk we carefully and deliberately make a sharp distinction between:

    a) address space consumption (what parts of the address space are  
in use)
    b) memory consumption (how many pages are in use)

The constants you cite below (HEAP_START, HEAP_END) relate to the  
_bounds_ on the usable address space.

Your query I think is actually about memory consumption, which is  
quite a different matter.   So -Xms and -Xmx can't/won't affect the  
static _bounds_ on what parts of the address space we'll ever use.    
They will affect how many pages we may have in use at any time, all of  
which must exist within our static bounds.

I hope this clarifies things for you.

--Steve

On 02/09/2009, at 8:26 AM, Peng Du wrote:

> Hello, everyone
>
> I have been looking for the class/object in either MMTk or Jikes that
> describes the layout of the object heap with no luck. The classes I
> have examined include: VM, Plan, Space, Memory, MemoryManager, and
> HeapGrowthManager.
>
> It appeared to me the HEAP_START, HEAP_END, AVAILABLE_START, and
> AVAILABLE_END in class VM are what I was looking for. However,
> these numbers seem to be never changed regardless of what -Xms and
> -Xmx are. Here is a printout from Space.printVMMap (GenMS):
>
> ===================================================
> Key: (I)mmortal (N)onmoving (D)iscontiguous (E)xtent (F)raction
>     HEAP_START 0x57000000
> AVAILABLE_START 0x5c800000
>       boot IN  0x57000000->0x66ffffff E 0x10000000
>   immortal IND []
>       meta  ND [0x68000000->0x693fffff, 0x67400000->0x677fffff]
>        los  ND [0x67c00000->0x67ffffff]
>     sanity  ND []
> non-moving  ND [0x67000000->0x673fffff]
>    sm-code  ND [0x67800000->0x67bfffff]
>    lg-code  ND []
>    nursery     0x95c00000->0x9fffffff F 0.15
>         ms  ND []
>  AVAILABLE_END 0xa0000000
>       HEAP_END 0xa0000000
> ===================================================
>
> What I am asking is:
>
> 1) Why are the those numbers fixed despite -Xms and -Xmx?
> 2) where can I obtain the precise and accurate information on the
> layout of the heap (extent and boundaries of each space)?
>
> Thanks
>
>
>
>
> ------------------------------------------------------------------------------
> 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

[Steve Blackburn]

Just FYI...   sourceforge does not deliver mail in order.   If you  
look at the full mail headers you'll see Daniel wrote & sent his email  
first, but sourceforge sat on it for 30mins before sending it out;  
just long enough for me to write a different response, which  
sourceforge then respectfully decided to deliver ahead of Daniel's :-)

Fortunately we did not contradict each other.   Hopefully the answer  
to Peng Du's question is clear.

--Steve

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

Thanks, Steve and Daniel

I sorta got the idea of the distinction between address space and memory
consumption. But as I did a simple calculation, the extent of the entire
HEAP is a little over 1Gb. (0xa0000000-0x57000000) >> 20 = 1168Mb

What if I set -Xmx to be over that and the application indeed consumes
over the 1168Mb. How would Jikes deal with this? Moreover, as Daniel
pointed out, the address space is allocated to each space in chunks.
Does that mean each space covers discontiguous address space?

Thanks




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

On 02/09/2009, at 12:18 PM, Peng Du wrote:
> I sorta got the idea of the distinction between address space and  
> memory
> consumption. But as I did a simple calculation, the extent of the  
> entire
> HEAP is a little over 1Gb. (0xa0000000-0x57000000) >> 20 = 1168Mb
>
> What if I set -Xmx to be over that and the application indeed consumes
> over the 1168Mb. How would Jikes deal with this?

It would fail (of course :-).

On 02/09/2009, at 9:23 AM, Steve Blackburn wrote:
>    a) address space consumption (what parts of the address space are
> in use)
>    b) memory consumption (how many pages are in use)

b) is strictly limited by a).

> Moreover, as Daniel
> pointed out, the address space is allocated to each space in chunks.
> Does that mean each space covers discontiguous address space?

It may.   This is configurable (discontiguous spaces make more  
efficient use of address space).  If you look at the verbose output  
you presented in an earlier email you'll see exactly which chunks each  
space is currently using.

--Steve

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

On Wed, 2 Sep 2009 12:25:17 +1000
Steve Blackburn <Steve.Blackburn@...> wrote:

> It would fail (of course :-).

Can I read this as: Jikes will never use more than 1168Mb
address space (physical memory) at any time?

Thanks


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

On 02/09/2009, at 12:40 PM, Peng Du wrote:

> On Wed, 2 Sep 2009 12:25:17 +1000
> Steve Blackburn <Steve.Blackburn@...> wrote:
>
>> It would fail (of course :-).
>
> Can I read this as: Jikes will never use more than 1168Mb
> address space (physical memory) at any time?

You can read it as:  Jikes RVM will never use more address space than  
it has available.

The concrete answer will depend on what system you're running on.

On IA32 the above 1GB limitation is overly restrictive.   There are  
two ways we can improve our utilization of address space:

        1) make the boot image relocatable and only use discontiguous  
spaces.   We've addressed a lot of that so the main remaining  
stumbling block is boot image relocation, which I've pushed on, but  
the main issue there is that some addresses are being compiled into  
the boot image code.

        2) use a 64 bit address space.   Jikes RVM already runs on 64 bit  
PPC.  Of course using a 64 bit address space does not come completely  
for free either (you have to somehow work with larger pointers, etc).

--Steve

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

I am working on a Intel x86_64 platform. So I might try building Jikes
with 64bit configuration. Don't know what stage it is currently in
though. I will try to see how Jikes works out.

Anyway, thank you all for the kind help and answers.



On Wed, 2 Sep 2009 13:22:18 +1000
Steve Blackburn <Steve.Blackburn@...> wrote:

>
> On 02/09/2009, at 12:40 PM, Peng Du wrote:
>
> > On Wed, 2 Sep 2009 12:25:17 +1000
> > Steve Blackburn <Steve.Blackburn@...> wrote:
> >
> >> It would fail (of course :-).
> >
> > Can I read this as: Jikes will never use more than 1168Mb
> > address space (physical memory) at any time?
>
> You can read it as:  Jikes RVM will never use more address space
> than it has available.
>
> The concrete answer will depend on what system you're running on.
>
> On IA32 the above 1GB limitation is overly restrictive.   There are  
> two ways we can improve our utilization of address space:
>
> 1) make the boot image relocatable and only use
> discontiguous spaces.   We've addressed a lot of that so the main
> remaining stumbling block is boot image relocation, which I've pushed
> on, but the main issue there is that some addresses are being
> compiled into the boot image code.
>
> 2) use a 64 bit address space.   Jikes RVM already runs on 64
> bit PPC.  Of course using a 64 bit address space does not come
> completely for free either (you have to somehow work with larger
> pointers, etc).
>
> --Steve
>
> ------------------------------------------------------------------------------
> 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

[Steve Blackburn]

Hi Peng Du,

Unfortunately Jikes RVM is not currently working on x86_64.   Ian  
Rogers has done a lot of work toward such a port, but as far as I know  
it does not yet include the optimizing compiler.

--Steve

On 02/09/2009, at 1:45 PM, Peng Du wrote:

> I am working on a Intel x86_64 platform. So I might try building Jikes
> with 64bit configuration. Don't know what stage it is currently in
> though. I will try to see how Jikes works out.
>
> Anyway, thank you all for the kind help and answers.
>
>
>
> On Wed, 2 Sep 2009 13:22:18 +1000
> Steve Blackburn <Steve.Blackburn@...> wrote:
>
>>
>> On 02/09/2009, at 12:40 PM, Peng Du wrote:
>>
>>> On Wed, 2 Sep 2009 12:25:17 +1000
>>> Steve Blackburn <Steve.Blackburn@...> wrote:
>>>
>>>> It would fail (of course :-).
>>>
>>> Can I read this as: Jikes will never use more than 1168Mb
>>> address space (physical memory) at any time?
>>
>> You can read it as:  Jikes RVM will never use more address space
>> than it has available.
>>
>> The concrete answer will depend on what system you're running on.
>>
>> On IA32 the above 1GB limitation is overly restrictive.   There are
>> two ways we can improve our utilization of address space:
>>
>> 1) make the boot image relocatable and only use
>> discontiguous spaces.   We've addressed a lot of that so the main
>> remaining stumbling block is boot image relocation, which I've pushed
>> on, but the main issue there is that some addresses are being
>> compiled into the boot image code.
>>
>> 2) use a 64 bit address space.   Jikes RVM already runs on 64
>> bit PPC.  Of course using a 64 bit address space does not come
>> completely for free either (you have to somehow work with larger
>> pointers, etc).
>>
>> --Steve
>>
>> ------------------------------------------------------------------------------
>> 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

[Ian Rogers (nabble)]

Hi Peng,

MRP (http://mrp.codehaus.org/) is probably what you are looking for.
The opt compiler is currently a work in progress but very near
completion (the instruction selection is rewritten, testing x64 and
educating the register allocator about calling conventions are
probably the biggest remaining issues). 64bit baseline compilation is
already working well, see the MRP mailing list for benchmark
results...

On 32bit x86 MRP we've worked with >1GB heaps, in particular MRP uses
a reserve and commit memory policy so that virtual memory is reserved
and then committed to being used. This is a common JVM technique and
avoids problems with shared library getting loaded into MMTk's address
space.

Regards,
Ian

2009/9/1 Steve Blackburn <Steve.Blackburn@...>:

> Hi Peng Du,
>
> Unfortunately Jikes RVM is not currently working on x86_64.   Ian
> Rogers has done a lot of work toward such a port, but as far as I know
> it does not yet include the optimizing compiler.
>
> --Steve
>
> On 02/09/2009, at 1:45 PM, Peng Du wrote:
>
>> I am working on a Intel x86_64 platform. So I might try building Jikes
>> with 64bit configuration. Don't know what stage it is currently in
>> though. I will try to see how Jikes works out.
>>
>> Anyway, thank you all for the kind help and answers.
>>
>>
>>
>> On Wed, 2 Sep 2009 13:22:18 +1000
>> Steve Blackburn <Steve.Blackburn@...> wrote:
>>
>>>
>>> On 02/09/2009, at 12:40 PM, Peng Du wrote:
>>>
>>>> On Wed, 2 Sep 2009 12:25:17 +1000
>>>> Steve Blackburn <Steve.Blackburn@...> wrote:
>>>>
>>>>> It would fail (of course :-).
>>>>
>>>> Can I read this as: Jikes will never use more than 1168Mb
>>>> address space (physical memory) at any time?
>>>
>>> You can read it as:  Jikes RVM will never use more address space
>>> than it has available.
>>>
>>> The concrete answer will depend on what system you're running on.
>>>
>>> On IA32 the above 1GB limitation is overly restrictive.   There are
>>> two ways we can improve our utilization of address space:
>>>
>>>      1) make the boot image relocatable and only use
>>> discontiguous spaces.   We've addressed a lot of that so the main
>>> remaining stumbling block is boot image relocation, which I've pushed
>>> on, but the main issue there is that some addresses are being
>>> compiled into the boot image code.
>>>
>>>      2) use a 64 bit address space.   Jikes RVM already runs on 64
>>> bit PPC.  Of course using a 64 bit address space does not come
>>> completely for free either (you have to somehow work with larger
>>> pointers, etc).
>>>
>>> --Steve
>>>
>>> ------------------------------------------------------------------------------
>>> 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

[Peng Du-2]

Dear Ian,

Thanks for bringing up MRP. I will try it out. It is nice to
see Jikes being actively developed and improved.

Thanks





On Wed, 2 Sep 2009 10:47:18 -0700
Ian Rogers <ian.rogers@...> wrote:

> Hi Peng,
>
> MRP (http://mrp.codehaus.org/) is probably what you are looking for.
> The opt compiler is currently a work in progress but very near
> completion (the instruction selection is rewritten, testing x64 and
> educating the register allocator about calling conventions are
> probably the biggest remaining issues). 64bit baseline compilation is
> already working well, see the MRP mailing list for benchmark
> results...
>
> On 32bit x86 MRP we've worked with >1GB heaps, in particular MRP uses
> a reserve and commit memory policy so that virtual memory is reserved
> and then committed to being used. This is a common JVM technique and
> avoids problems with shared library getting loaded into MMTk's address
> space.
>
> Regards,
> Ian
>
> 2009/9/1 Steve Blackburn <Steve.Blackburn@...>:
> > Hi Peng Du,
> >
> > Unfortunately Jikes RVM is not currently working on x86_64.   Ian
> > Rogers has done a lot of work toward such a port, but as far as I
> > know it does not yet include the optimizing compiler.
> >
> > --Steve
> >
> > On 02/09/2009, at 1:45 PM, Peng Du wrote:
> >
> >> I am working on a Intel x86_64 platform. So I might try building
> >> Jikes with 64bit configuration. Don't know what stage it is
> >> currently in though. I will try to see how Jikes works out.
> >>
> >> Anyway, thank you all for the kind help and answers.
> >>
> >>
> >>
> >> On Wed, 2 Sep 2009 13:22:18 +1000
> >> Steve Blackburn <Steve.Blackburn@...> wrote:
> >>
> >>>
> >>> On 02/09/2009, at 12:40 PM, Peng Du wrote:
> >>>
> >>>> On Wed, 2 Sep 2009 12:25:17 +1000
> >>>> Steve Blackburn <Steve.Blackburn@...> wrote:
> >>>>
> >>>>> It would fail (of course :-).
> >>>>
> >>>> Can I read this as: Jikes will never use more than 1168Mb
> >>>> address space (physical memory) at any time?
> >>>
> >>> You can read it as:  Jikes RVM will never use more address space
> >>> than it has available.
> >>>
> >>> The concrete answer will depend on what system you're running on.
> >>>
> >>> On IA32 the above 1GB limitation is overly restrictive.   There
> >>> are two ways we can improve our utilization of address space:
> >>>
> >>>      1) make the boot image relocatable and only use
> >>> discontiguous spaces.   We've addressed a lot of that so the main
> >>> remaining stumbling block is boot image relocation, which I've
> >>> pushed on, but the main issue there is that some addresses are
> >>> being compiled into the boot image code.
> >>>
> >>>      2) use a 64 bit address space.   Jikes RVM already runs on 64
> >>> bit PPC.  Of course using a 64 bit address space does not come
> >>> completely for free either (you have to somehow work with larger
> >>> pointers, etc).
> >>>
> >>> --Steve
> >>>
> >>> ------------------------------------------------------------------------------
> >>> 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

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