Future of JRockit & Tools Or finding the right layer to attack Joakim Dahlstedt 15 September 2004
A Short Background on JRockit Server-centric JVM Java compatible (most of the Java libraries are Suns) Available free of charge (as any other JVM) Uses adaptive optimization code generation, memory management, locking primitives Built-in observability Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 2
Background JRockit - Continued Code Execution No interpreter JIT-Compiler Dynamically optimizing compiler Ability to save code to disc Memory-management Concurrent or Stop-the world GC Single-spaced or Generational GC Ability to switch between these on-the-fly In summary Mostly very similar to Sun s Hotspot or IBM JDK Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 3
Performance - Getting Good Enough Code Performance is very seldomly an issue Exceptions trading & high performance computing GC is sometimes an issue Need better predictability Memory footprint is sometimes an issue Java is getting mature Still the list of things to do is infinite Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 4
What s Problem With An Infinite List? The Compiler Writer s dilemma There will always be more optimizations This means the list of optimizations is infinite Hard problem: infinite list of opportunities, which task is the best at this point? Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 5
The Layer Phenomenon App App JVM App JVM JVM Why? HW HW HW 1998 Goal 2004 Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 6
Share the Burden My belief: share the burden with the developers Translate problems we can t solve into something that makes sense to them that they can solve Can t we solve the upper layer problems in the VEE itself? Why is the translation needed? Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 7
VEEs Can t Solve Some Problems VEE optimizations cannot attack algorithmical inefficiencies (at least not yet) VEE optimizations cannot attack memory leaks VEE optimizations cannot attack some structural inefficiencies. Two choices: Ignore problem we can t solve it Expose problem to the developers help them solve the problem Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 8
A Glance At Large Systems In a large system it s hard to find the bottlenecks No single developer knows the whole system The project is using multiple third components These 3rd party components are using other 3rd party compoents Many these components may not even have been tried together ever before. Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 9
Change Perspective The Normal User does not know what happens far underneath her Data Reporting from the VEE At best report what happens from its viewpoint Excludes much data Abstraction becomes a burden To understand the data you need to know a lot about the lower layers The VEE needs to switch perspective Transform data to a form that makes sense to the user Expose data that the user really can take advantage of without knowing all about all the lower layers Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 10
Exposing VEE data Execution data Lock contention data Memory leak information Pause-times Cache-miss patterns Exposing this data is almost free Part of the normal adaptive optimization phase Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 11
JRockit Runtime Analyzer Started off as a tool for internal purposes Collect customer profiles for future optimization opportunities A poor man s profiler Method execution profile GC profile Exception information Two phased approach Generate data dump Use GUI tool to analyze the data Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 12
JRockit - Memory Leak Detection We are the memory management system It s relatively easy for us to answer questions like Is this application growing? What types are growing? Which types points to this type? Who points to this particular instance? In addition it is fairly easy for us to Give this information to the user at anytime To tell the user exactly when a certain structure is updated Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 13
JRockit - Expose the Memory Wall VEE vendors know memory latency is a problem We are not exposing the problem to upper layers In fact hardware is fairly bad at exposing the cache-misses (e.g. on Intel architectures its hard to access this data from user mode) Provide cache-miss data by Java-source line Work with tool vendors to make sure there are new memory latency perspectives in the profiling tools. Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 14
Upper Layers & VEE cooperation No matter were we draw the line: upper layers have to communicate with the lower layers lower-layers have to communicate with the upper layers e.g. JSR 166 java.util.concurrency e.g. WMI perfmon VEEs should provide means for upper layers to communicate performance data to lower layers Invitational Workshop on the Future of VEEs September 2004-2004 BEA Systems, Inc. 15
www.bea.com