Article: Nehalem Performance Preview
By: Henrik S (henrik.stahl.delete@this.nospam.oracle.nothanks.com), April 12, 2009 8:25 am
Room: Moderated Discussions
EduardoS (no@spam.com) on 4/12/09 wrote:
---------------------------
>Henrik S (henrik.stahl@nospam.oracle.nothanks.com) on 4/12/09 wrote:
>---------------------------
>>It's JRockit with a J. Yes, you enable large pages with a -Xlargepages flag, which
>>will use large pages both for JIT compiled code and the Java heap, to avoid ITLB
>>and DLTB misses respectively. Java is susceptible to both of these issues; ITLB
>>because many J2EE apps tend to have very big code bases and DLTB because of the random access nature of the Java heap.
>
>Any try with Linux huge pages?
Huh? Our large (== huge) pages support work on both Windows and Linux. You must of course configure the OS appropriately first.
>>Apart from that, we don't use the OS much for SPECjbb2005. Threads are mapped 1-to-1
>>to OS threads, so thread scheduling matters a bit.
>
>This one surprised me, I never profiled JBB, but always expected it to create/destroy a lot of threads.
What I mean is that Java threads are mapped 1x1 to OS threads. This has not always been the case in JRockit, we used to maintain a "thin thread" mxn mapping.
Thread scheduling matters because if the OS is not conservative and frequently changes the CPU a thread is scheduled on, it will destroy any memory locality that the JVM has managed to create (eg during memory allocation, or during GC). Pretty basic and not all all specific to Java.
jbb creates threads at the start of each warehouse run, and then lets them terminate at the end of the warehous run. Warehouse runs are ramped up from 1 to 2xCPU count threads, with 30/240s runtime per iteration for warmup/scoring respectively. See the jbb docs on http://www.spec.org for more detail.
Henrik
---------------------------
>Henrik S (henrik.stahl@nospam.oracle.nothanks.com) on 4/12/09 wrote:
>---------------------------
>>It's JRockit with a J. Yes, you enable large pages with a -Xlargepages flag, which
>>will use large pages both for JIT compiled code and the Java heap, to avoid ITLB
>>and DLTB misses respectively. Java is susceptible to both of these issues; ITLB
>>because many J2EE apps tend to have very big code bases and DLTB because of the random access nature of the Java heap.
>
>Any try with Linux huge pages?
Huh? Our large (== huge) pages support work on both Windows and Linux. You must of course configure the OS appropriately first.
>>Apart from that, we don't use the OS much for SPECjbb2005. Threads are mapped 1-to-1
>>to OS threads, so thread scheduling matters a bit.
>
>This one surprised me, I never profiled JBB, but always expected it to create/destroy a lot of threads.
What I mean is that Java threads are mapped 1x1 to OS threads. This has not always been the case in JRockit, we used to maintain a "thin thread" mxn mapping.
Thread scheduling matters because if the OS is not conservative and frequently changes the CPU a thread is scheduled on, it will destroy any memory locality that the JVM has managed to create (eg during memory allocation, or during GC). Pretty basic and not all all specific to Java.
jbb creates threads at the start of each warehouse run, and then lets them terminate at the end of the warehous run. Warehouse runs are ramped up from 1 to 2xCPU count threads, with 30/240s runtime per iteration for warmup/scoring respectively. See the jbb docs on http://www.spec.org for more detail.
Henrik
Topic | Posted By | Date |
---|---|---|
Nehalem review up | David Kanter | 2009/04/07 02:43 AM |
Nehalem review up | noone | 2009/04/07 05:48 AM |
Strange jbb on Harpertown | Henrik S | 2009/04/07 07:29 AM |
Strange jbb on Harpertown | David Kanter | 2009/04/07 10:19 AM |
Strange jbb on Harpertown | Henrik S | 2009/04/07 08:33 PM |
Strange jbb on Harpertown | Chris | 2009/04/07 11:54 PM |
Strange jbb on Harpertown | Henrik S | 2009/04/08 01:40 AM |
Nehalem review up | Vincent Diepeveen | 2009/04/07 07:34 AM |
Nehalem review up | Jack | 2009/04/09 03:51 PM |
Nehalem review up | Vincent Diepeveen | 2009/04/10 12:58 AM |
Nehalem review up | Michael S | 2009/04/10 02:45 AM |
Nehalem review up | EduardoS | 2009/04/10 06:01 AM |
Nehalem review up | Michael S | 2009/04/10 06:56 AM |
Nehalem review up | Eugene Nalimov | 2009/04/10 08:12 AM |
Choice of C compiler doesn't matter much for Java... | Henrik S | 2009/04/10 09:10 AM |
Choice of C compiler doesn't matter much for Java... | EduardoS | 2009/04/10 01:49 PM |
Choice of C compiler doesn't matter much for Java... | Henrik S | 2009/04/11 06:13 AM |
Choice of C compiler doesn't matter much for Java... | EduardoS | 2009/04/11 10:30 AM |
Large pages | David Kanter | 2009/04/11 01:02 PM |
Choice of C compiler doesn't matter much for Java... | Henrik S | 2009/04/11 10:06 PM |
Choice of C compiler doesn't matter much for Java... | Paul | 2009/04/12 12:53 AM |
Choice of C compiler doesn't matter much for Java... | iz | 2009/04/12 01:59 AM |
Choice of C compiler doesn't matter much for Java... | Henrik S | 2009/04/12 06:37 AM |
Choice of C compiler doesn't matter much for Java... | EduardoS | 2009/04/12 07:08 AM |
Choice of C compiler doesn't matter much for Java... | Henrik S | 2009/04/12 08:25 AM |
Choice of C compiler doesn't matter much for Java... | EduardoS | 2009/04/12 04:24 PM |
Choice of C compiler doesn't matter much for Java... | Henrik S | 2009/04/12 09:18 PM |
Thread costs | David Kanter | 2009/04/12 11:12 PM |
Thread costs | Henrik S | 2009/04/14 01:08 PM |
Choice of C compiler doesn't matter much for Java... | Michael S | 2009/04/11 07:53 AM |
Choice of C compiler doesn't matter much for Java... | Henrik S | 2009/04/11 10:08 PM |
Nehalem review up | Vincent Diepeveen | 2009/04/11 03:50 PM |
Nehalem review up | Michael S | 2009/04/11 04:12 PM |
Nehalem review up | Vincent Diepeveen | 2009/04/12 02:01 AM |
Nehalem review up | Michael S | 2009/04/12 04:07 AM |
Nehalem review up | rwessel | 2009/04/07 01:01 PM |
Nehalem review up | slacker | 2009/04/08 08:11 AM |
Energy vs. power | David Kanter | 2009/04/08 09:11 AM |
Energy vs. power | Vincent Diepeveen | 2009/04/10 01:08 AM |
Energy vs. power | slacker | 2009/04/10 08:26 AM |
Energy vs. power | RagingDragon | 2009/04/10 09:19 AM |
Energy vs. power | David Kanter | 2009/04/10 10:47 AM |
Energy vs. power | Jack | 2009/04/10 03:44 PM |
Energy vs. power | slacker | 2009/04/10 06:00 PM |
Energy vs. power | Jack | 2009/04/10 06:31 PM |
Energy vs. power | David Kanter | 2009/04/10 11:16 PM |
Nehalem review up | rwessel | 2009/04/08 01:32 PM |
Minor font issue | gpriatko | 2009/04/07 03:35 PM |
Minor HTML issue | David Kanter | 2009/04/07 08:38 PM |
Minor HTML issue | David Kanter | 2009/04/07 08:39 PM |
Good work, i look forward to linux and SP2 numbers (NT) | PiedPiper | 2009/04/08 12:52 AM |
Nehalem review up | Joe Chang | 2009/04/10 02:59 AM |