Menu
▾
▴
jikesrvm-researchers
|
From: Peng Du <pd...@cs...> - 2009-08-28 21:45:53
|
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 |
|
From: Colin(Du Li) <daw...@gm...> - 2009-08-28 22:49:38
|
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 > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > -- View this message in context: http://www.nabble.com/-rvm-research--Call-Magic-in-MMTk-tp25197395p25198132.html Sent from the jikesrvm-researchers mailing list archive at Nabble.com. |
|
From: lltong <ll...@cs...> - 2009-08-30 05:55:39
|
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 > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > -- Regards, Liangliang Tong |
|
From: Robin G. <rob...@an...> - 2009-08-31 01:04:00
|
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 >> Jik...@li... >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> >> > > |
|
From: Peng Du <pd...@cs...> - 2009-08-31 02:43:46
|
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 <rob...@an...> 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
> >> Jik...@li...
> >> 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
> Jik...@li...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
|
|
From: Robin G. <rob...@an...> - 2009-08-31 05:36:38
|
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. > > > |
|
From: Peng Du <pd...@cs...> - 2009-08-31 15:18:58
|
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 <rob...@an...> 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 > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers |
|
From: Peng Du <pd...@cs...> - 2009-08-31 21:47:17
|
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 <pd...@cs...> 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 <rob...@an...> 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 > > Jik...@li... > > 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 > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers |
|
From: Peng Du <pd...@cs...> - 2009-09-01 22:26:55
|
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
|
|
From: Steve B. <Ste...@an...> - 2009-09-01 23:24:17
|
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
> Jik...@li...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
|
|
From: Daniel F. <zyr...@zy...> - 2009-09-01 23:35:31
|
> > 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. |
|
From: Steve B. <Ste...@an...> - 2009-09-01 23:58:24
|
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 |
|
From: Peng Du <pd...@cs...> - 2009-09-02 02:18:39
|
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 |
|
From: Steve B. <Ste...@an...> - 2009-09-02 02:31:09
|
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 |
|
From: Peng Du <pd...@cs...> - 2009-09-02 02:41:03
|
On Wed, 2 Sep 2009 12:25:17 +1000 Steve Blackburn <Ste...@an...> 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 |
|
From: Steve B. <Ste...@an...> - 2009-09-02 03:22:38
|
On 02/09/2009, at 12:40 PM, Peng Du wrote: > On Wed, 2 Sep 2009 12:25:17 +1000 > Steve Blackburn <Ste...@an...> 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 |
|
From: Peng Du <pd...@cs...> - 2009-09-02 03:45:46
|
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 <Ste...@an...> wrote: > > On 02/09/2009, at 12:40 PM, Peng Du wrote: > > > On Wed, 2 Sep 2009 12:25:17 +1000 > > Steve Blackburn <Ste...@an...> 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 > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers |
|
From: Steve B. <Ste...@an...> - 2009-09-02 03:52:02
|
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 <Ste...@an...> wrote: > >> >> On 02/09/2009, at 12:40 PM, Peng Du wrote: >> >>> On Wed, 2 Sep 2009 12:25:17 +1000 >>> Steve Blackburn <Ste...@an...> 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 >> Jik...@li... >> 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 > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers |
|
From: Ian R. <ian...@ma...> - 2009-09-02 17:47:28
|
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 <Ste...@an...>: > 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 <Ste...@an...> wrote: >> >>> >>> On 02/09/2009, at 12:40 PM, Peng Du wrote: >>> >>>> On Wed, 2 Sep 2009 12:25:17 +1000 >>>> Steve Blackburn <Ste...@an...> 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 >>> Jik...@li... >>> 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 >> Jik...@li... >> 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 > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > |
|
From: Peng Du <pd...@cs...> - 2009-09-02 17:54:10
|
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...@ma...> 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 <Ste...@an...>: > > 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 <Ste...@an...> wrote: > >> > >>> > >>> On 02/09/2009, at 12:40 PM, Peng Du wrote: > >>> > >>>> On Wed, 2 Sep 2009 12:25:17 +1000 > >>>> Steve Blackburn <Ste...@an...> 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 > >>> Jik...@li... > >>> 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 > >> Jik...@li... > >> 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 > > Jik...@li... > > 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 > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers |
Thanks for helping keep SourceForge clean.
X