There is a host of data here
that shows you many of the characteristics of the benchmarks.
For example, jython allocates 1183MB of objects, with a maximum live
size of 100KB (excluding the heap that JikesRVM needs for itself).
Given a reasonable-size heap, using a generational collector, it would
be unusual for jython to cause a major GC (look at the column "Nursery
Survival Bytes" in the second table).
If by "memory intensive" you mean "allocates a high volume", then jython
is fairly memory intensive. In a full-heap collector, jython tends to
have a relatively high GC time, but in a generational collector it doesn't.
The longest running benchmark in the dacapo 2006-10 release is eclipse -
this is also one of the heaviest allocating benchmarks so may be a good
Another way to increase run time is to decrease heap size, again if
that's appropriate to the evaluation you're doing.
PS, ignore the stats for xalan - there was a bug in the classpath <->
Jikes RVM interface at the time. It now allocates much less memory.
On 04/07/13 20:54, Andreas Sewe wrote:
> Hi Joydeep,
>> I am running the jython module in Dacapo-2006-10.jar since I read in
>> some papers that this module is memory-intensive. The problem is that
>> the test gets over in 5477 msec and I have to run this test for at least
>> 200 seconds to observe some results. I am using this command- “java -jar
>> dacapo-2006-10.jar jython”. Is there a way I can run this test so that
>> it runs for at least 200 seconds.
> first of all, consider using the latest version of DaCapo (9.12); the
> workloads in 9.12 are typically larger than the workloads of the same
> name in 2006-10.
> Also, consider changing the input size (parameter "-s"). DaCapo 9.12
> offers small, default, larger, and huge inputs, although not all sizes
> are available for all benchmarks.
> That being said, neither of these suggestions alone will solve your
> problem, as the DaCapo benchmarks were specifically designed to finish
> *one* iteration in less than a minute on modern hardware.
> Now, you may of course run multiple iterations (parameter "-n").
> However, you should be aware that this runs the same piece of code with
> the same inputs essentially n times in a loop. This may or may not be
> "realistic" enough for the evaluation you have in mind.
> Hope that helps.
> This SF.net email is sponsored by Windows:
> Build for Windows Store.
> dacapobench-researchers mailing list