Leon Rosenberg wrote:
Ok, my fault,
read "page" and "java" in one sentence -> map to Java Page -> Java
Server Page. Must be a circuit error in the brain.
Anyway, does it mean, that a proper configured JVM on an opteron
processor, will be significantly faster? Could be very interesting for
caches...
It depends on the number of memory pages your memory controller has to
manage. I don't know the details about Opteron TLB (and didn't read the
article carefully enough). So if your working set size is small I doubt
any positive impact. If you use large memory/CPU the difference might be
noticable.
Modern CPUs have on chip performance counters to find out. I know, that
at least from a SPARC chip you can get the number of TLB misses from on
chip performance registers (using cpustat/cputrack under Solaris).
cpustat works for Opteron on Solaris 10 x86 too. Under Linux there seems
to be perfctr patches (see:
http://www.rz.rwth-aachen.de/computing/events/2006/sunhpc_2006/05_Smith.ppt)
Opteron has a lot of performance counters. You will find the ones
supported by cpustat on
http://opensolaris.org/os/community/observability/hardware/cpc/
Leon
On 4/3/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
Using large pages to eliminate TLB misses has nothing to do with the
size of the objects. From the view of the operating system java heap is
just a huge and continuous chunk of memory. Anything what's inside is
managed by the JVM. But whenever the JVM needs to access an adress it
needs to make an address calculation as described in the article. Once
the needed adress translation tables do not fit into the TLB,
performance gets bad. Since Java often uses a large and continuous heap
it's a very good candidate for using large pages, saving entries in the TLB.
Leon Rosenberg wrote:
Hi,
recently I found (ok actually our sysadmin did) this articles on the
web, and wanted to share some thoughts.
http://www.devx.com/amd/Article/30529
http://www.devx.com/amd/Article/30785
The article describes, that using opteron and large memory pages can
give significant performance wins. I don't doubt this, but I doubt,
that large memory pages are a real use case in the tomcat / java
webapps world. At least in applications I saw there are always many
small objects, tags, beans, dtos.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
