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