Rock-style Transactional Memory - Lock Elision for Java, etc.

In Applications of the Adaptive Transactional Memory Test Platform to appear in Transact 2008 we should how Rock-like transactional memory can be applied to various components of the Solaris software stack, including transactional lock elision for "synchronized" blocks in Java.

Comments:

Hi, I've been searching the Net for Java code level optimizations that make good use of the CPU cache and leverage CPU features like Loop-pipelining and stuff like that. Are there any specific rules/best practices for such things?

PS: How do you analyze if your Java program is thrashing the L1/L2 cache?

Posted by Ashwin Jayaprakash on March 06, 2008 at 09:43 AM EST #

Hi Ashwin,

Taking your 2nd question 1st, you'd use the same tools for a Java program as you would any native C/C++ program. The answer will be platform-dependent, but briefly you'll want tools that read or otherwise query the hardware performance counters. On Solaris SunStudio Collect&Analyze works nicely. If you like lower-level tools then cpustat, cputrack and busstat are a good choice. Generally I screen for problems with the latter family and then use the former to zero in on the worst offenders in the code.

Back to the 1st question,
once you become proficient with such tools you can tune your code accordingly.

Regards, -Dave

Posted by Dave Dice on March 15, 2008 at 07:59 AM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Dave

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today