
Gil Tene
Vice President of Technology and CTO, Co-Founder
gil@azulsystems.com

Dr. Cliff Click
Chief JVM Architect, Distinguished Engineer
Azul Systems
cliffc@azulsystems.com

Michael Wolf
Distinguished Engineer
Azul Systems
wolf@azulsystems.com
|
|
2008 JavaOne Conference
May 6-9, 2008
San Francisco, California
Moscone Center
http://java.sun.com/javaone/sf/index.jsp
Join Cliff Click, Michael Wolf, and Gil Tene in the
following Session Talks:
About the Talk
| Technical Session Details |
Session ID: |
TS-6237 |
Session Title: |
Debugging Data Races |
Session Abstract: |
With multicore systems becoming the norm,
every programmer is being forced to deal with multi-CPU memory
atomicity bugs: data races. Data race bugs are some of the hardest
bugs to find and fix, sometimes taking weeks on end to deal
with, even for experts. There are very few tools to help here
(and these are mostly just academic implementations, FindBugs
being a rare exception). This session’s speakers are at
the forefront of multicore Java™ technology-based systems
and have to debug data races daily. They have a lot of hard-won
experiences with finding and fixing such bugs, and they share
them with you in this session.
Download the presentation: Debugging Data Races »
|
Track: |
Java Platform, Standard Edition (Java SE) |
Date and Time: |
Wednesday, May 07, 13:30 pm - 14:30 pm |
Room: |
Moscone Center - Gateway 102/103 |
Speaker/Company: |
Siva Annamalai, Azul Systems; Cliff
Click, Azul Systems |
| Technical Session Details |
Session ID: |
TS-6256 |
Session Title: |
Toward a Coding Style for Scalable
Nonblocking Data Structures |
Session Abstract: |
Nonblocking (NB) algorithms are something
of a Holy Grail of concurrent programming--typically very fast,
even under heavy load, they come with hard guarantees about
forward progress. The downside is that they are very hard to
get right. This session’s speakers have been working on
writing some nonblocking utilities over the last year (open
sourced on SourceForge in the high-scale-lib project) and have
made some progress toward a coding style that can be used to
build a variety of NB data structures: hash tables, sets, work
queues, and bit vectors. These data structures scale much better
than even the concurrent JDK™ software utilities while
providing the same correctness guarantees. They usually have
similar overheads at the low end while scaling incredibly well
on high-end hardware.
The coding style is still very immature but shows clear promise.
It stems from a handful of basic premises: You don’t hide
payload during updates; any thread can complete (or ignore)
any in-progress update; use flat arrays for quick access and
broadest-possible striping; and use parallel, concurrent, incremental
array copy. At the core is a simple state-machine description
of the update logic.
Download the presentation: Toward a Coding Style for Scalable Nonblocking Data Structures »
|
Track: |
Java Platform, Standard Edition (Java SE) |
Date and Time: |
Thursday, May 08,
13:30 pm - 14:30 pm |
Room: |
Moscone Center - Gateway 102/103 |
Speaker/Company: |
Cliff Click, Azul Systems; Balaji
Iyengar, Azul Systems |
| Technical Session Details |
Session ID: |
TS-6500 |
Session Title: |
Performance Considerations in Concurrent
Garbage-Collected Systems |
Session Abstract: |
This session examines specific considerations
introduced by the recent availability of various concurrent
(non-stop-the-world) garbage-collected environments. An overview
of important modeling and tuning considerations unique to concurrent
garbage collection (GC) specifically covers the delicate interplay
between GC cycle time, object allocation rates, available free
heap, and garbage collection policy.
The presentation discusses and explains relevant GC terminology
and phrases common in concurrent and mostly concurrent GC, focusing
on their effects and relationship to metrics such as heap size,
real and effective live set size, and object allocation rates.
These include concurrent and mostly concurrent marking, live
set and card marking, generational operation, and compaction.
The session includes specific examples of concurrent GC behavior
with a wide variety of heap sizes, live set sizes, and allocation
rates. It demonstrates the sampling of behavior across a characterized
range, from idle all the way to the “collapse” point
of a certain configuration. It also shows results based on heap
sizes and live set sizes from 1 Gbyte to 300 Gbytes as well
as allocation rates from “idle” all the way up to
30 Gbytes per second.
Download the presentation: Performance Considerations in Concurrent Garbage-Collected Systems » |
Track: |
Java Platform, Standard Edition (Java SE) |
Date and Time: |
Thursday, May 08,
16:10 pm - 17:10 pm |
Room: |
Moscone Center - Esplanade 304/306 |
Speaker/Company: |
Gil Tene, Azul Systems; Michael Wolf, Azul Systems |
| Technical Session Details |
Session ID: |
TS-6500 |
Session Title: |
Performance Considerations in Concurrent
Garbage-Collected Systems |
Session Abstract: |
This session examines specific considerations
introduced by the recent availability of various concurrent
(non-stop-the-world) garbage-collected environments. An overview
of important modeling and tuning considerations unique to concurrent
garbage collection (GC) specifically covers the delicate interplay
between GC cycle time, object allocation rates, available free
heap, and garbage collection policy.
The presentation discusses and explains relevant GC terminology
and phrases common in concurrent and mostly concurrent GC, focusing
on their effects and relationship to metrics such as heap size,
real and effective live set size, and object allocation rates.
These include concurrent and mostly concurrent marking, live
set and card marking, generational operation, and compaction.
The session includes specific examples of concurrent GC behavior
with a wide variety of heap sizes, live set sizes, and allocation
rates. It demonstrates the sampling of behavior across a characterized
range, from idle all the way to the “collapse” point
of a certain configuration. It also shows results based on heap
sizes and live set sizes from 1 Gbyte to 300 Gbytes as well
as allocation rates from “idle” all the way up to
30 Gbytes per second.
Download the presentation: Performance Considerations in Concurrent Garbage-Collected Systems » |
Track: |
Java Platform, Standard Edition (Java SE) |
Date and Time: |
Friday , May 09,
10:50 am - 11:50 am |
Room: |
Moscone Center - Esplanade 303 |
Speaker/Company: |
Gil Tene, Azul Systems; Michael Wolf,
Azul Systems |
| Technical Session Details |
Session ID: |
TS-6206 |
Session Title: |
JVM™ Challenges and Directions
in the Multicore Era |
Session Abstract: |
Available core counts are going up, up, up!
Intel is shipping quad-core chips; Sun’s Rock has (effectively)
64 CPUs and Azul’s hardware nearly a thousand cores. How
do we use all those cores effectively? The JVM™ machine
proper can directly make use of a small number of cores (JIT
compilation, profiling), and garbage collection can use about
20 percent more cores than the application is using to make
garbage--but this hardly gets us to four cores. Application
servers and transactional—Java™ 2 Platform, Enterprise
Edition (J2EE™ platform)/bean--applications scale well
with thread pools to about 40 or 60 CPUs, and then internal
locking starts to limit scaling. Unless your application, such
as a data mining; risk analysis; or, heaven forbid, Fortran-style
weather-prediction application has embarrassingly parallel data,
how can you use more CPUs to get more performance? How do you
debug the million-line concurrent program?
“Locking” paradigms (lock ranking, visual inspection)
appear to be nearing the limits of program sizes that are understandable
and maintainable. “Transactions,” the hot new academic
solution to concurrent-programming woes, has its own unsolved
issues (open nesting, “wait,” livelock, significant
slowdowns without contention). Neither locks nor transactions
provide compiler support for keeping the correct variables guarded
by the correct synchronization, such as atomic sets. Application-specific
programming, such as stream programming or graphics, is, well,
application-specific. Tools (debuggers, static analyzers, profilers)
and libraries (JDK™ software concurrent utilities) are
necessary but not sufficient. Where is the general-purpose concurrent
programming model? This session’s speaker claims that
we need another revolution in thinking about programs.
Download the presentation: Challenges and Directions in the Multicore Era »
|
Track: |
Java SE |
Date and Time: |
Friday, May 09,
16:10 pm - 17:10 pm |
Room: |
Moscone Center -Gateway 104 |
Speaker/Company: |
Cliff Click, Azul Systems; Brian
Goetz, Sun Microsystems, Inc. |
|