outofmemory error on building

View: New views
5 Messages — Rating Filter:   Alert me  

outofmemory error on building

by pankajsejwal :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

to find the control flow i was inserting  VM.sysWriteln method and i didn have any problem initially but later it started showing Javaoutofmemory:java heap size sort of error.
is there a way to increase heap size permanently  on openjdk coz after javac ,java is called instantly and there is no way to intercept.
please share what ever info u have on it...!
thanks..

Re: [rvm-research] outofmemory error on building

by Michael Bond :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

You can increase the heap size for the build by modifying the maxmemory
variable in the following snippet from build.xml:

     <echo message="Building bootimage. Output redirected to : ${build.base}/BootImageWriterOutput.txt"/>
     <echo message="MMTk properties = ${mmtk.properties}"/>
     <java classname="org.jikesrvm.tools.bootImageWriter.BootImageWriter"
           fork="yes"
           maxmemory="500M"
           failonerror="false"
           resultproperty="bootimage-writer.result"
           dir="${basedir}/tools/bootImageWriter/src">
       <classpath>
         <pathelement location="${build.bootimage-writer.dir}"/>
         <path refid="rvm.class.path"/>
       </classpath>

Could you please let us know your name and affiliation?

Cheers,
Mike


On Mon, 28 Sep 2009, pankajsejwal wrote:

>
> to find the control flow i was inserting  VM.sysWriteln method and i didn
> have any problem initially but later it started showing Javaoutofmemory:java
> heap size sort of error.
> is there a way to increase heap size permanently  on openjdk coz after javac
> ,java is called instantly and there is no way to intercept.
> please share what ever info u have on it...!
> thanks..
> --
> View this message in context: http://www.nabble.com/outofmemory--error-on-building-tp25643001p25643001.html
> Sent from the jikesrvm-researchers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

Re: [rvm-research] outofmemory error on building

by pankajsejwal :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

thanks for replying sir,
sir my name is:Pankaj Sejwal
Affiliation(if I understand it right):Birla Institute of engineering and Science,Pilani,India. I am persuing ME(master of engineering) in Computer Science and we are using Jikes RVM to learn advanced compilation techniques.
I am to  implement " Thread specific heap" on this platform.
some things i m not able to understand is that what is actual relation b/w space and allocators.
What i want to do is that i want to find out if an object is local or global so that i can bring it around in same space but the escape analysis says that it sorts out registers and hashes them to put in buckets, what is the exact meaning of registers here where is should have been objects?

Second thing I wanted to know is that allocation if I am to bother about then do I have to worry about any particular GC or I can pic anyone(coz it has been specified that every plan has its own way of working on heap).
When i take NOGC, after initializing heap it proceeds to get monotone page resource which is showing "Currently unimplemented",if it is so then why control goes there?

Third problem is that to find control i am employing VM.syswriteln and Log.write methods but even for very small programs I am getting some particular functions being called excessively and some not even once.I realized that there are two calls to stack allocation even if no class is provide to rvm to execute.

thanks
Michael Bond wrote:
Hi,

You can increase the heap size for the build by modifying the maxmemory
variable in the following snippet from build.xml:

     <echo message="Building bootimage. Output redirected to : ${build.base}/BootImageWriterOutput.txt"/>
     <echo message="MMTk properties = ${mmtk.properties}"/>
     <java classname="org.jikesrvm.tools.bootImageWriter.BootImageWriter"
           fork="yes"
           maxmemory="500M"
           failonerror="false"
           resultproperty="bootimage-writer.result"
           dir="${basedir}/tools/bootImageWriter/src">
       <classpath>
         <pathelement location="${build.bootimage-writer.dir}"/>
         <path refid="rvm.class.path"/>
       </classpath>

Could you please let us know your name and affiliation?

Cheers,
Mike


On Mon, 28 Sep 2009, pankajsejwal wrote:

>
> to find the control flow i was inserting  VM.sysWriteln method and i didn
> have any problem initially but later it started showing Javaoutofmemory:java
> heap size sort of error.
> is there a way to increase heap size permanently  on openjdk coz after javac
> ,java is called instantly and there is no way to intercept.
> please share what ever info u have on it...!
> thanks..
> --
> View this message in context: http://www.nabble.com/outofmemory--error-on-building-tp25643001p25643001.html
> Sent from the jikesrvm-researchers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jikesrvm-researchers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

Re: [rvm-research] outofmemory error on building

by Robin Garner :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

pankajsejwal wrote:
> thanks for replying sir,
> sir my name is:Pankaj Sejwal
> Affiliation(if I understand it right):Birla Institute of engineering and
> Science,Pilani,India. I am persuing ME(master of engineering) in Computer
> Science and we are using Jikes RVM to learn advanced compilation techniques.
> I am to  implement " Thread specific heap" on this platform.
> some things i m not able to understand is that what is actual relation b/w
> space and allocators.

Essentially a Space is a global, shared object that represents a virtual
memory region managed under the same allocation and collection policy.

An Allocator is a thread-local object that allows a thread to allocate
from a Space.  Typically the Allocator will allocate one or more chunks
of memory from the global Space, and then return smaller chunks to the
application.  This way the majority of allocations are unsynchronized
(being thread-local), periodically performing synchronized allocation
from the global Space.

You can see a correspondence with the components of a plan, for example
in MS.java (the global mark-sweep plan object), we have

   public static final MarkSweepSpace msSpace =
     new MarkSweepSpace("ms", DEFAULT_POLL_FREQUENCY, VMRequest.create());

ie a global MarkSweepSpace is created.  Then in the per-thread MSMutator
class,

   protected MarkSweepLocal ms = new MarkSweepLocal(MS.msSpace);

each thread acquires its own MarkSweepLocal, a subclass of Allocator.

> What i want to do is that i want to find out if an object is local or global
> so that i can bring it around in same space but the escape analysis says
> that it sorts out registers and hashes them to put in buckets, what is the
> exact meaning of registers here where is should have been objects?
>
> Second thing I wanted to know is that allocation if I am to bother about
> then do I have to worry about any particular GC or I can pic anyone(coz it
> has been specified that every plan has its own way of working on heap).
> When i take NOGC, after initializing heap it proceeds to get monotone page
> resource which is showing "Currently unimplemented",if it is so then why
> control goes there?

The NoGC plan is not designed for running real programs, since it can't
perform garbage collection.  In the first instance you're probably best
off looking at one of the stable full-heap collectors, MarkSweep or
SemiSpace.

I'm not sure I understand your specific question - could you point to a
particular line of code ?

> Third problem is that to find control i am employing VM.syswriteln and
> Log.write methods but even for very small programs I am getting some
> particular functions being called excessively and some not even once.I
> realized that there are two calls to stack allocation even if no class is
> provide to rvm to execute.

Remember that JikesRVM itself uses the heap, and since JikesRVM is a
compile-only VM, you will see a lot of allocation even when running a
simple "hello world" application.

Another approach you might try if you want to understand the call
hierarchy of MMTk is to use a profiler like jip
(http://jiprof.sourceforge.net/) against the MMTk harness.

Here's an example from some profiling I was doing recently (omitting
some of the harness internals and vmmagic calls)

  30199   9184.6    163.3     9.8     0.2  | | | | | |
+--GenMSMutator:alloc     (org.mmtk.plan.generational.marksweep)
  30199   9021.3    149.5     9.6     0.2  | | | | | | |
+--GenMutator:alloc     (org.mmtk.plan.generational)
  30199   8871.8    449.6     9.4     0.5  | | | | | | | |
+--BumpPointer:alloc  (org.mmtk.utility.alloc)
  30199   2333.9    157.0     2.5     0.2  | | | | | | | | |
+--Allocator:alignAllocationNoFill  (org.mmtk.utility.alloc)
  30199   2176.8   1207.2     2.3     1.3  | | | | | | | | | |
+--Allocator:alignAllocation      (org.mmtk.utility.alloc)
  30140   1351.6    243.8     1.4     0.3  | | | | | | | | |
+--Allocator:fillAlignmentGap       (org.mmtk.utility.alloc)
     59   4496.6      1.2     4.8          | | | | | | | | |
+--BumpPointer:allocSlow    (org.mmtk.utility.alloc)
     59   4492.7      1.2     4.8          | | | | | | | | | |
+--Allocator:allocSlowInline      (org.mmtk.utility.alloc)
     59      0.1      0.1     0.0          | | | | | | | | | | |
+--Stats:gcCount        (org.mmtk.utility.statistics)
     59      0.1      0.1     0.0          | | | | | | | | | | |
+--BumpPointer:getSpace (org.mmtk.utility.alloc)
     59   4491.1      3.5     4.8          | | | | | | | | | | |
+--BumpPointer:allocSlowOnce    (org.mmtk.utility.alloc)
     59     11.5      1.5     0.0          | | | | | | | | | | | |
+--Conversions:bytesToPages   (org.mmtk.utility)
     59      5.0      1.1     0.0          | | | | | | | | | | | | |
+--Conversions:bytesToPagesUp       (org.mmtk.utility)
     59      1.9      0.8     0.0          | | | | | | | | | | | | |
+--Conversions:pagesToAddress       (org.mmtk.utility)
     59   4431.3      2.9     4.7          | | | | | | | | | | | |
+--Space:acquire      (org.mmtk.policy)
     59      0.1      0.1     0.0          | | | | | | | | | | | | |
+--Plan:gcInProgress        (org.mmtk.plan)
     59      0.1      0.1     0.0          | | | | | | | | | | | | |
+--Plan:isInitialized       (org.mmtk.plan)
     59      0.1      0.1     0.0          | | | | | | | | | | | | |
+--Collection:isEmergencyAllocation (org.mmtk.harness.vm)
     59      4.2      0.9     0.0          | | | | | | | | | | | | |
+--PageResource:reservePages        (org.mmtk.utility.heap)
     59      1.7      0.9     0.0          | | | | | | | | | | | | | |
+--PageResource:lock      (org.mmtk.utility.heap)
     59      0.1      0.1     0.0          | | | | | | | | | | | | | | |
+--Plan:gcInProgress    (org.mmtk.plan)
     59      0.7      0.4     0.0          | | | | | | | | | | | | | | |
+--JavaLock:acquire     (org.mmtk.harness.scheduler.javathreads)> thanks
     59      0.1      0.1     0.0          | | | | | | | | | | | | | |
+--MonotonePageResource:adjustForMetaData (org.mmtk.utility.heap)
     59      1.5      0.7     0.0          | | | | | | | | | | | | | |
+--PageResource:unlock    (org.mmtk.utility.heap)
     59      0.1      0.1     0.0          | | | | | | | | | | | | | | |
+--Plan:gcInProgress    (org.mmtk.plan)
     59      0.7      0.5     0.0          | | | | | | | | | | | | | | |
+--JavaLock:release     (org.mmtk.harness.scheduler.javathreads)
     59   4404.6      0.4     4.7          | | | | | | | | | | | | |
+--PageResource:getNewPages (org.mmtk.utility.heap)
     59   4404.1      4.0     4.7          | | | | | | | | | | | | | |
+--MonotonePageResource:allocPages        (org.mmtk.utility.heap)
     59      1.3      0.7     0.0          | | | | | | | | | | | | | | |
+--PageResource:lock    (org.mmtk.utility.heap)
     59      0.1      0.1     0.0          | | | | | | | | | | | | | | |
| +--Plan:gcInProgress  (org.mmtk.plan)
     59      0.4      0.2     0.0          | | | | | | | | | | | | | | |
| +--JavaLock:acquire   (org.mmtk.harness.scheduler.javathreads)
     59      2.5      0.9     0.0          | | | | | | | | | | | | | | |
+--Space:chunkAlign     (org.mmtk.policy)
     59      3.4      0.7     0.0          | | | | | | | | | | | | | | |
+--Conversions:pagesToBytes     (org.mmtk.utility)
     59      2.7      0.8     0.0          | | | | | | | | | | | | | | |
+--PageResource:commitPages     (org.mmtk.utility.heap)
     59      0.1      0.1     0.0          | | | | | | | | | | | | | | |
| +--MonotonePageResource:adjustForMetaData     (org.mm


The first column is the invocation count - you can see a sharp
difference between the fast-path (thread-local, Allocator) and the
slow-path (global, Space).

You can get this profile by running

< download and unpack jip into $HOME/tools >
$ ant mmtk-harness
$ export JIP=$HOME/tools/jip-1.1.1/profile/profile.jar
$ java -Xbootclasspath/a:$JIP -javaagent:$JIP \
     -jar target/mmtk/mmtk-harness.jar \
     MMTk/harness/test-scripts/Quicksort.script \
     plan=org.mmtk.plan.generational.marksweep.GenMS initHeap=5m

There could well be other tools

Regards,
Robin

>
> Michael Bond wrote:
>> Hi,
>>
>> You can increase the heap size for the build by modifying the maxmemory
>> variable in the following snippet from build.xml:
>>
>>      <echo message="Building bootimage. Output redirected to :
>> ${build.base}/BootImageWriterOutput.txt"/>
>>      <echo message="MMTk properties = ${mmtk.properties}"/>
>>      <java classname="org.jikesrvm.tools.bootImageWriter.BootImageWriter"
>>            fork="yes"
>>            maxmemory="500M"
>>            failonerror="false"
>>            resultproperty="bootimage-writer.result"
>>            dir="${basedir}/tools/bootImageWriter/src">
>>        <classpath>
>>          <pathelement location="${build.bootimage-writer.dir}"/>
>>          <path refid="rvm.class.path"/>
>>        </classpath>
>>
>> Could you please let us know your name and affiliation?
>>
>> Cheers,
>> Mike
>>
>>
>> On Mon, 28 Sep 2009, pankajsejwal wrote:
>>
>>> to find the control flow i was inserting  VM.sysWriteln method and i didn
>>> have any problem initially but later it started showing
>>> Javaoutofmemory:java
>>> heap size sort of error.
>>> is there a way to increase heap size permanently  on openjdk coz after
>>> javac
>>> ,java is called instantly and there is no way to intercept.
>>> please share what ever info u have on it...!
>>> thanks..
>>> --
>>> View this message in context:
>>> http://www.nabble.com/outofmemory--error-on-building-tp25643001p25643001.html
>>> Sent from the jikesrvm-researchers mailing list archive at Nabble.com.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9-12, 2009. Register
>>> now!
>>> http://p.sf.net/sfu/devconf
>>> _______________________________________________
>>> Jikesrvm-researchers mailing list
>>> Jikesrvm-researchers@...
>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9-12, 2009. Register
>> now!
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Jikesrvm-researchers mailing list
>> Jikesrvm-researchers@...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>
>>
>


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

Re: [rvm-research] outofmemory error on building

by pankajsejwal () :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

thanks a lot for this precise information sir..
the question I was trying to put about escape analysis is

simpleEscape.java

 if (escapes.threadLocal) {
        result.setThreadLocal(reg, true);
      }
      if (escapes.methodLocal) {
        result.setMethodLocal(reg, true);
      }

from here the control is sent to

FI_EscapeSummary.java

 void setThreadLocal(Register r, boolean b) {
    if (b) {
      hash.put(r, THREAD_LOCAL);
    } else {
      hash.put(r, MAY_ESCAPE_THREAD);

then it says that it hashes them in buckets and sets the buckets accordingly.I am not able to understand that classification of buckets is on basis of what? Do they get set on the basis of thread active for the application? If it is so how can i find for which thread it is being done??
Is flow insensitive escape analysis the best variation of escape analysis?

Another thing that I think is that even if i don't know the objects in their true form i can use scheduler to find thread id  of currently executing thread and use a hashmap<threadid,register,THREAD_LOCAL> to make a combination??

I wanted one more info please if i try to divide space run time from memory manager what r the possible places i might have to maipulate like accounting..?

please respond to my question...
Robin Garner wrote:
pankajsejwal wrote:
> thanks for replying sir,
> sir my name is:Pankaj Sejwal
> Affiliation(if I understand it right):Birla Institute of engineering and
> Science,Pilani,India. I am persuing ME(master of engineering) in Computer
> Science and we are using Jikes RVM to learn advanced compilation techniques.
> I am to  implement " Thread specific heap" on this platform.
> some things i m not able to understand is that what is actual relation b/w
> space and allocators.

Essentially a Space is a global, shared object that represents a virtual
memory region managed under the same allocation and collection policy.

An Allocator is a thread-local object that allows a thread to allocate
from a Space.  Typically the Allocator will allocate one or more chunks
of memory from the global Space, and then return smaller chunks to the
application.  This way the majority of allocations are unsynchronized
(being thread-local), periodically performing synchronized allocation
from the global Space.

You can see a correspondence with the components of a plan, for example
in MS.java (the global mark-sweep plan object), we have

   public static final MarkSweepSpace msSpace =
     new MarkSweepSpace("ms", DEFAULT_POLL_FREQUENCY, VMRequest.create());

ie a global MarkSweepSpace is created.  Then in the per-thread MSMutator
class,

   protected MarkSweepLocal ms = new MarkSweepLocal(MS.msSpace);

each thread acquires its own MarkSweepLocal, a subclass of Allocator.

> What i want to do is that i want to find out if an object is local or global
> so that i can bring it around in same space but the escape analysis says
> that it sorts out registers and hashes them to put in buckets, what is the
> exact meaning of registers here where is should have been objects?
>
> Second thing I wanted to know is that allocation if I am to bother about
> then do I have to worry about any particular GC or I can pic anyone(coz it
> has been specified that every plan has its own way of working on heap).
> When i take NOGC, after initializing heap it proceeds to get monotone page
> resource which is showing "Currently unimplemented",if it is so then why
> control goes there?

The NoGC plan is not designed for running real programs, since it can't
perform garbage collection.  In the first instance you're probably best
off looking at one of the stable full-heap collectors, MarkSweep or
SemiSpace.

I'm not sure I understand your specific question - could you point to a
particular line of code ?

> Third problem is that to find control i am employing VM.syswriteln and
> Log.write methods but even for very small programs I am getting some
> particular functions being called excessively and some not even once.I
> realized that there are two calls to stack allocation even if no class is
> provide to rvm to execute.

Remember that JikesRVM itself uses the heap, and since JikesRVM is a
compile-only VM, you will see a lot of allocation even when running a
simple "hello world" application.

Another approach you might try if you want to understand the call
hierarchy of MMTk is to use a profiler like jip
(http://jiprof.sourceforge.net/) against the MMTk harness.

Here's an example from some profiling I was doing recently (omitting
some of the harness internals and vmmagic calls)

  30199   9184.6    163.3     9.8     0.2  | | | | | |
+--GenMSMutator:alloc     (org.mmtk.plan.generational.marksweep)
  30199   9021.3    149.5     9.6     0.2  | | | | | | |
+--GenMutator:alloc     (org.mmtk.plan.generational)
  30199   8871.8    449.6     9.4     0.5  | | | | | | | |
+--BumpPointer:alloc  (org.mmtk.utility.alloc)
  30199   2333.9    157.0     2.5     0.2  | | | | | | | | |
+--Allocator:alignAllocationNoFill  (org.mmtk.utility.alloc)
  30199   2176.8   1207.2     2.3     1.3  | | | | | | | | | |
+--Allocator:alignAllocation      (org.mmtk.utility.alloc)
  30140   1351.6    243.8     1.4     0.3  | | | | | | | | |
+--Allocator:fillAlignmentGap       (org.mmtk.utility.alloc)
     59   4496.6      1.2     4.8          | | | | | | | | |
+--BumpPointer:allocSlow    (org.mmtk.utility.alloc)
     59   4492.7      1.2     4.8          | | | | | | | | | |
+--Allocator:allocSlowInline      (org.mmtk.utility.alloc)
     59      0.1      0.1     0.0          | | | | | | | | | | |
+--Stats:gcCount        (org.mmtk.utility.statistics)
     59      0.1      0.1     0.0          | | | | | | | | | | |
+--BumpPointer:getSpace (org.mmtk.utility.alloc)
     59   4491.1      3.5     4.8          | | | | | | | | | | |
+--BumpPointer:allocSlowOnce    (org.mmtk.utility.alloc)
     59     11.5      1.5     0.0          | | | | | | | | | | | |
+--Conversions:bytesToPages   (org.mmtk.utility)
     59      5.0      1.1     0.0          | | | | | | | | | | | | |
+--Conversions:bytesToPagesUp       (org.mmtk.utility)
     59      1.9      0.8     0.0          | | | | | | | | | | | | |
+--Conversions:pagesToAddress       (org.mmtk.utility)
     59   4431.3      2.9     4.7          | | | | | | | | | | | |
+--Space:acquire      (org.mmtk.policy)
     59      0.1      0.1     0.0          | | | | | | | | | | | | |
+--Plan:gcInProgress        (org.mmtk.plan)
     59      0.1      0.1     0.0          | | | | | | | | | | | | |
+--Plan:isInitialized       (org.mmtk.plan)
     59      0.1      0.1     0.0          | | | | | | | | | | | | |
+--Collection:isEmergencyAllocation (org.mmtk.harness.vm)
     59      4.2      0.9     0.0          | | | | | | | | | | | | |
+--PageResource:reservePages        (org.mmtk.utility.heap)
     59      1.7      0.9     0.0          | | | | | | | | | | | | | |
+--PageResource:lock      (org.mmtk.utility.heap)
     59      0.1      0.1     0.0          | | | | | | | | | | | | | | |
+--Plan:gcInProgress    (org.mmtk.plan)
     59      0.7      0.4     0.0          | | | | | | | | | | | | | | |
+--JavaLock:acquire     (org.mmtk.harness.scheduler.javathreads)> thanks
     59      0.1      0.1     0.0          | | | | | | | | | | | | | |
+--MonotonePageResource:adjustForMetaData (org.mmtk.utility.heap)
     59      1.5      0.7     0.0          | | | | | | | | | | | | | |
+--PageResource:unlock    (org.mmtk.utility.heap)
     59      0.1      0.1     0.0          | | | | | | | | | | | | | | |
+--Plan:gcInProgress    (org.mmtk.plan)
     59      0.7      0.5     0.0          | | | | | | | | | | | | | | |
+--JavaLock:release     (org.mmtk.harness.scheduler.javathreads)
     59   4404.6      0.4     4.7          | | | | | | | | | | | | |
+--PageResource:getNewPages (org.mmtk.utility.heap)
     59   4404.1      4.0     4.7          | | | | | | | | | | | | | |
+--MonotonePageResource:allocPages        (org.mmtk.utility.heap)
     59      1.3      0.7     0.0          | | | | | | | | | | | | | | |
+--PageResource:lock    (org.mmtk.utility.heap)
     59      0.1      0.1     0.0          | | | | | | | | | | | | | | |
| +--Plan:gcInProgress  (org.mmtk.plan)
     59      0.4      0.2     0.0          | | | | | | | | | | | | | | |
| +--JavaLock:acquire   (org.mmtk.harness.scheduler.javathreads)
     59      2.5      0.9     0.0          | | | | | | | | | | | | | | |
+--Space:chunkAlign     (org.mmtk.policy)
     59      3.4      0.7     0.0          | | | | | | | | | | | | | | |
+--Conversions:pagesToBytes     (org.mmtk.utility)
     59      2.7      0.8     0.0          | | | | | | | | | | | | | | |
+--PageResource:commitPages     (org.mmtk.utility.heap)
     59      0.1      0.1     0.0          | | | | | | | | | | | | | | |
| +--MonotonePageResource:adjustForMetaData     (org.mm


The first column is the invocation count - you can see a sharp
difference between the fast-path (thread-local, Allocator) and the
slow-path (global, Space).

You can get this profile by running

< download and unpack jip into $HOME/tools >
$ ant mmtk-harness
$ export JIP=$HOME/tools/jip-1.1.1/profile/profile.jar
$ java -Xbootclasspath/a:$JIP -javaagent:$JIP \
     -jar target/mmtk/mmtk-harness.jar \
     MMTk/harness/test-scripts/Quicksort.script \
     plan=org.mmtk.plan.generational.marksweep.GenMS initHeap=5m

There could well be other tools

Regards,
Robin

>
> Michael Bond wrote:
>> Hi,
>>
>> You can increase the heap size for the build by modifying the maxmemory
>> variable in the following snippet from build.xml:
>>
>>      <echo message="Building bootimage. Output redirected to :
>> ${build.base}/BootImageWriterOutput.txt"/>
>>      <echo message="MMTk properties = ${mmtk.properties}"/>
>>      <java classname="org.jikesrvm.tools.bootImageWriter.BootImageWriter"
>>            fork="yes"
>>            maxmemory="500M"
>>            failonerror="false"
>>            resultproperty="bootimage-writer.result"
>>            dir="${basedir}/tools/bootImageWriter/src">
>>        <classpath>
>>          <pathelement location="${build.bootimage-writer.dir}"/>
>>          <path refid="rvm.class.path"/>
>>        </classpath>
>>
>> Could you please let us know your name and affiliation?
>>
>> Cheers,
>> Mike
>>
>>
>> On Mon, 28 Sep 2009, pankajsejwal wrote:
>>
>>> to find the control flow i was inserting  VM.sysWriteln method and i didn
>>> have any problem initially but later it started showing
>>> Javaoutofmemory:java
>>> heap size sort of error.
>>> is there a way to increase heap size permanently  on openjdk coz after
>>> javac
>>> ,java is called instantly and there is no way to intercept.
>>> please share what ever info u have on it...!
>>> thanks..
>>> --
>>> View this message in context:
>>> http://www.nabble.com/outofmemory--error-on-building-tp25643001p25643001.html
>>> Sent from the jikesrvm-researchers mailing list archive at Nabble.com.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9-12, 2009. Register
>>> now!
>>> http://p.sf.net/sfu/devconf
>>> _______________________________________________
>>> Jikesrvm-researchers mailing list
>>> Jikesrvm-researchers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9-12, 2009. Register
>> now!
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Jikesrvm-researchers mailing list
>> Jikesrvm-researchers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>
>>
>


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Jikesrvm-researchers mailing list
Jikesrvm-researchers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers