Please try the lastest SVN head, I have just committed a fix.
 
Cheers,
Daniel.

On Fri, Mar 18, 2011 at 3:18 AM, Lokesh Gidra <lokesh.gidra@yahoo.com> wrote:


I tried with -Xms1G & -Xmx2G but it still reports OOM. On the contrary, sunflow benchmark runs fine on all other GCs with a tight heap bound of 1M and 50M for initial and maximum heap sizes respectively.

Regards,
Lokesh


----- Original Message -----
> From:Steve Blackburn <Steve.Blackburn@anu.edu.au>
> To:Lokesh Gidra <lokesh.gidra@yahoo.com>; Discussion of day-to-day development and design among JikesRVM core team members <jikesrvm-core@lists.sourceforge.net>
> Cc:
> Sent:Thursday, 17 March 2011 12:30 PM
> Subject:Re: [rvm-core] Getting Out of Memory error with StickyImmix GC on all the dacapo benchmarks
>
> I suggest you experiment with different heap sizes.  (-Xms & -Xmx).   The
> next question is to establish whether the behavior of stickyimmix is
> "unreasonable" compared to other garbage collectors.  If not, then
> there's probably no problem with stickyimmix.   If so we should explore the
> problem further.
>
> --Steve
>
> On 17/03/2011, at 9:53 PM, Lokesh Gidra wrote:
>
> > Hi,
> >
> >
> > I used the following command line:
> >
> >
> > $ ./jikesrvm/dist/FastAdaptiveStickyImmix_x86_64-linux/rvm -jar
> dacapo-9.12-bach.jar sunflow
> >
> >
> > Thanks,
> > Lokesh
> >
> >> ----- Original Message -----
> >>> From:Steve Blackburn <Steve.Blackburn@anu.edu.au>
> >>> To:Lokesh Gidra <lokesh.gidra@yahoo.com>; Discussion of
> day-to-day
> >> development and design among JikesRVM core team members
> >> <jikesrvm-core@lists.sourceforge.net>
> >>> Cc:
> >>> Sent:Wednesday, 16 March 2011 11:29 PM
> >>> Subject:Re: [rvm-core] Getting Out of Memory error with StickyImmix
> GC on
> >> all the dacapo benchmarks
> >>>
> >>> Please tell us what command line arguments you used.
> >>>
> >>> --Steve
> >>>
> >>> On 17/03/2011, at 4:51 AM, Lokesh Gidra wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I am getting out of memory error with StickyImmix garbage
> collector on
> >>
> >>> unmodified jikes while running any of the dacapo benchmarks. The
> trace is
> >> as
> >>> follows:
> >>>>
> >>>> java.lang.reflect.InvocationTargetException
> >>>> java.lang.reflect.InvocationTargetException
> >>>>     at java.lang.Exception.<init>(Exception.java:90)
> >>>>     at
> >>>
> >>
> java.lang.reflect.InvocationTargetException.<init>(InvocationTargetException.java:98)
> >>>>     at
> >>>
> >>
> java.lang.reflect.InvocationTargetException.<init>(InvocationTargetException.java:86)
> >>>>     at
> >>>
> >>
> java.lang.reflect.VMCommonLibrarySupport.construct(VMCommonLibrarySupport.java:438)
> >>>>     at
> java.lang.reflect.VMConstructor.construct(VMConstructor.java:87)
> >>>>     at
> java.lang.reflect.Constructor.newInstance(Constructor.java:317)
> >>>>     at
> >> org.dacapo.harness.TestHarness.runBenchmark(TestHarness.java:211)
> >>>>     at
> org.dacapo.harness.TestHarness.main(TestHarness.java:171)
> >>>>     at Harness.main(Harness.java:17)
> >>>> Caused by: java.lang.reflect.InvocationTargetException
> >>>>     at java.lang.Exception.<init>(Exception.java:90)
> >>>>     at
> >>>
> >>
> java.lang.reflect.InvocationTargetException.<init>(InvocationTargetException.java:98)
> >>>>     at
> >>>
> >>
> java.lang.reflect.InvocationTargetException.<init>(InvocationTargetException.java:86)
> >>>>     at
> >>>
> >>
> java.lang.reflect.VMCommonLibrarySupport.construct(VMCommonLibrarySupport.java:438)
> >>>>     at
> java.lang.reflect.VMConstructor.construct(VMConstructor.java:87)
> >>>>     at
> java.lang.reflect.Constructor.newInstance(Constructor.java:317)
> >>>>     at org.dacapo.harness.Xalan.<init>(Xalan.java:38)
> >>>>     at
> >>>
> >>
> org.jikesrvm.classloader.ReflectionBase$$Reflect39593.invokeInternal(Unknown
> >>> Source:0)
> >>>>     at
> >> org.jikesrvm.runtime.ReflectionBase.invoke(ReflectionBase.java:180)
> >>>>     at
> org.jikesrvm.runtime.Reflection.invoke(Reflection.java:74)
> >>>>     at
> >>>
> >>
> java.lang.reflect.VMCommonLibrarySupport.construct(VMCommonLibrarySupport.java:436)
> >>>>     ...5 more
> >>>> Caused by: java.lang.OutOfMemoryError
> >>>>     <<No stacktrace available>>
> >>>>
> >>>> Please help me with this.
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Lokesh
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> ------------------------------------------------------------------------------
> >>>> Colocation vs. Managed Hosting
> >>>> A question and answer guide to determining the best fit
> >>>> for your organization - today and in the future.
> >>>> http://p.sf.net/sfu/internap-sfd2d
> >>>> _______________________________________________
> >>>> Jikesrvm-core mailing list
> >>>> Jikesrvm-core@lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > _______________________________________________
> > Jikesrvm-core mailing list
> > Jikesrvm-core@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jikesrvm-core




------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core