Thanks all for your replying. I have run several times with different Java options for Map/Reduce tasks. However there is no much difference.
Following is the example of my test setting: Test A: -Xmx1024m -server -XXlazyUnlocking -XlargePages -XgcPrio:deterministic -XXallocPrefetch -XXallocRedoPrefetch Test B: -Xmx1024m Test C: -Xmx1024m -XXaggressive Is there any tricky or special setting for Jrockit vm on Hadoop? In the Hadoop Quick Start guides, it says that "JavaTM 1.6.x, preferably from Sun". Is there any concern about the Jrockit performance issue? I'd highly appreciate for your time and consideration. On Fri, May 8, 2009 at 7:36 AM, JQ Hadoop <jq.had...@gmail.com> wrote: > There are a lot of tuning "knobs" for the JRockit JVM when it comes to > performance; those tuning can make a huge difference. I'm very interested > if > there are some tuning tips for Hadoop. > > Grace, what are the parameters that you used in your testing? > > Thanks, > JQ > > On Thu, May 7, 2009 at 11:35 PM, Steve Loughran <ste...@apache.org> wrote: > > > Chris Collins wrote: > > > >> a couple of years back we did a lot of experimentation between sun's vm > >> and jrocket. We had initially assumed that jrocket was going to scream > >> since thats what the press were saying. In short, what we discovered > was > >> that certain jdk library usage was a little bit faster with jrocket, but > for > >> core vm performance such as synchronization, primitive operations the > sun vm > >> out performed. We were not taking account of startup time, just raw > code > >> execution. As I said, this was a couple of years back so things may of > >> changed. > >> > >> C > >> > > > > I run JRockit as its what some of our key customers use, and we need to > > test things. One lovely feature is tests time out before the stack runs > out > > on a recursive operation; clearly different stack management at work. > > Another: no PermGenHeapSpace to fiddle with. > > > > * I have to turn debug logging of in hadoop test runs, or there are > > problems. > > > > * It uses short pointers (32 bits long) for near memory on a 64 bit JVM. > So > > your memory footprint on sub-4GB VM images is better. Java7 promises > this, > > and with the merger, who knows what we will see. This is unimportant on > > 32-bit boxes > > > > * debug single stepping doesnt work. That's ok, I use functional tests > > instead :) > > > > I havent looked at outright performance. > > > > / > > >
