Home > devoxx > Devoxx – Day 2

Devoxx – Day 2

This was a tough day for me, I got a very bad cold (the weather here is far worse than London) and it took loads of strength to go to the conference (as a side note I noticed that the sponsors’ booths are already there, one day earlier than usual). Anyway, I started my day with three hours of Java tuning by attending the

Java Performance by Kirk Pepperdine and Holly Cummins

I was a bit late for this talk since I arrived there ten minutes after it had started. I got there right after Kirk had explained the reasons why a Java application might be performing badly. After that he showed a demo of a web based application connecting to a server that was taking long to reply.

Each software system has dynamic and static aspects. Dynamic aspects include components such actors (usage patterns) and static aspects include components that do not change or manage/provide resources. Al these factors put load on our system. Each Java system can be further divided into:

  • the application that does all the processing (it provides locks and includes external systems)
  • the virtual machine (it manages the memory and the hardware)
  • the hardware (this is not shareable and you have to have exclusive access to it). the hardware manages the CPU, the disk i/o, the memory and the network connections.

In multithreaded systems loads of time is spent on waiting, every time we want to use a shared resource and someone else is using it we have to wait. So we might experience poor response times with possible reasons

  • overflow is queued on every level
  • hardware lacks capacity
  • bad JVM implementation

At the beginning we don’t really know anything about the cause of the bad performance. All we know is that the users are experiencing poor performance. This poor performance can be either at the operating system level, virtual machine level or application level (or on all simultaneously)

The operating system induced latency

  • hardware management
  • symptoms include
    • relative high CPU utilisation
  • high rates of context switching

The virtual machine induced latency

  • Java heap memory management
    • object creation
    • garbage collection
  • symptoms include
    • high rates of object creation
    • low garbage collection throughput
    • likely to see high CPU utilisation

The application induced latency

  • locks block thread from making forward progress (queuing)
  • synchronous calls to external systems park threads

This latency is always expressed by inflated user response times.

If we have high CPU consumption the candidate consumers of CPU are the application (in this case we need to do execution profiling), the JVM (in this case we need to do memory profiling) or the os.

There is a wrinkle in all these:

  • JVM and application run in the same user process.
  • Differentiate by monitoring the garbage collection.
  • The operating system needs to be reported separately
  • The operating system will prevent CPUs from being fully utilised
  • Kernel utilisation is a significant portion of overall utilisation
  • High rates of interrupt handling or context switching.

The implications of the above are:

  • applications are asking too much of the operating system
  • thread scheduling
  • system calls

So how do we start our tests? We need to set up a test environment and do a benchmarking.

In order to expose kernel counters we can use the following command line tools: vmstat, mpstat, corestat. In order to monitor the garbage collection we can use:

  • jvm switch -verbose gc
  • gchisto analysis tool (new)
  • hpjmeter

At this point the speakers presented a demo with a tool called health centre by IBM.

As a synopsis when garbage collection throughput is very high we need to do object creation profiling. When application execution time is very high we need to do execution profiling.

We can diagnose CPU bound

  • code is being invoked more than it needs to be (easy done with event-driven models)
  • an algorithm is not the most efficient (easily done without algorithms research)

Fixing CPU bound application requires knowledge of what code is being run

  • identity methods suitable for optimisation (optimise methods which the application doesn’t spend time on is a waste of time)
  • identify methods where more time is being spent than you expect
  • “why is so much of my profile in calls to this trivial little method?”

There are two ways to work put what code is application is doing: trace and profiling


  • does not require specialist tools (but is better with them)
  • records every invocation of a subset of methods
  • gives insight into sequence of events
  • in the simplest case System.out.println


  • samples all methods and provides statistics

Method profiling

  • validates algorithm performance
    • where is the application spending its time
    • am I getting benefits from that?
  • identify methods where application is spending lots of time
  • why are they being called? can calls be reduced?
  • identify branches where time is being spent

The IBM health centre it is designed to be

  • live monitoring of applications
  • capabilities in a number of areas
  • method profiling
  • garbage collection
  • locking
  • configuration
  • visualisation and recommendations

At this point the speakers did a benchmark (process by which we will measure and investigate performance) their demo application by using Apache JMeter and Grinder.

In order to configure the benchmarking environment

  • mirror production (box tells us, change a layer, change in the problem)
  • ensure adequate hardware for test harness (harness should not be the bottleneck)

preliminary steps:

  • review performance targets
  • plan on how to bring test to steady state
  • enable appropriate level of monitoring
  • too much will affect baseline results
  • system counters
  • gc
  • external system performance

To establish a workload

  • fixed amount of work measure the time
  • fixed amount of time measure the work

Stumbling points when we set up the environment

  • noise
  • randomisation and caching (systems are very good at caching, we cache everywhere)
  • randomisation and access patterns
  • complex usage patterns (really hard to cope with these things)
  • complex system interactions
  • stubbing out external systems
  • use mocks

At this point the showed an Apache JMeter demo. JMeter is a closed system which means it

  • supports limited number of users
  • user re-joins the line as soon as it is finished
    • source of artificial latency
  • sell throttling
  • difficult to regulate request arrival rates (thread starvation)

On the other hands open systems have:

  • unlimited number of users
    • users arrive according to some schedule
  • possible to flood a system (this is desirable because if your systems performs poorly you want it to flood)

closed harness when no of users is fixed
open harness when no of users is not fixed

The garbage collection it’s more than collecting objects, it’s memory management. it can provide performance benefits by faster freeing of memory, by providing faster memory allocation and by providing faster memory access. Even in C freeing memory can be expensive with malloc/free.

Allocating memory also takes time and is particular slow when you have loads of threads and one heap (the threads will be fighting for the heap).

Finally not all access memory is equally fast. Garbage collection can speed up memory access by rearranging objects in memory.

Memory access is slow compared to instruction processing. To prevent memory access from being a bottleneck, memory caches are added since access to objects that are already in the cache is faster. On top of that most modern systems have a hierarchy of caches of increasing speed and decreasing size. When an object is loaded into the cache its neighbours are also loaded into the cache. This makes relative position of objects very important to memory access.

the garbage collector can hinder or help interaction with the cache

  • cache pollution
  • depending on the algorithm gc may visit quite a memory during collection
  • the cache won’t be right for the applciation because it will be full of stuff the gc collection just visited
  • compaction
    • means are closer to their neighbours and morelikely to be in the cache
    • re-arrangement
    • objects are closer to their friends and more likely to be in the cache at the right time

Most JVMs provide more than one garbage collection algorithm. None of the policies are bad, but the default is not necessarily the best in every circumstance. All the different garbage collectors differ in the following

  • when and how the work is done?
  • what happens to garbage?
  • how is the heap laid out?

There are three types of garbage collectors:

  • stop the world garbage collector
    • all application threads stop
  • incremental
    • divided into smaller portions
  • concurrent
    • happens at the same time with the application.

Even when the garbage collector spends loads of time pausing application performance might be better. Why? because garbage collection is not just a garbage collection.

At this point they presented another demo of the Memory Visualizer tool that’s focused just on garbage collection. This tools works with all the VMs (the health centre works only with IBM VM).

And yet another demo with Eclipse Memory Analyzer tool this time.

Pro Spring 2.5 (with Joris Kuipers and Arjen Poutsma)

Another three-hours session, an overview of the new Spring 2.5 features.

Spring 2.5 is one of the first major frameworks with dedicated support for Java 6. It supports all new JDK 1.6 APIs supported (JDBC 4, JMX, JDK ServiceLoader API). JDK1.4 and 1.5 still supported but there is no JDK 1.3 support.

There is improved JDBC support:

  • JDBC 4.0
    • native connections (java.sql.Wrapper)
    • LOB handling (setBlob/setClob)
    • new SQLException subclasses.
  • other JDBC improvements
    • SimpleJdbcTemplate
    • SimpleJdbcCall and SimpleJdbcInsert

They have added support for named parameters when we use the JdbcTemplate.

They have added support for JMX MX beans. MXBeans are a new addition to JMX and they provide better support for bundling related values (standard beans require custom classes). MXBeans can be registered by MBeanExporter (the JMX spec does not allow dynamic creation).

The new JDK ServiceLoader API (java.util.ServiceLoader) is use to register the service providers for services. The file META-INF/services/my.service defines the implementation classes for my.service. This is used by Service(List)FactoryBean

Spring 2.5 also supports the Java 6 built-in HTTP server. It also supports HTTP-based remoting using SimpleHttpInvokerServiceExporter and SimpleHessian/BurlapServiceExporter. You can set up a JRE 1.6 HttpServer by using SimpleHttpServerFactoryBean.

Java EE 5 support

  • integrates seamlessly
  • new Java EE 5 APIs supported
    • Servlet 2.5, JSP 2.1 and JSF 1.2
    • JTA 1.1, JAX_WS 2.0 and JavaMail 2.4
  • J2EE 1.4 and 1.3 still fully supported
    • eg BEA WebLogic 8.1 and higher
    • eg IBM WebShere 1.5 and above.

    But in Spring 3 they will drop J2EE 1.3 compatibility.

    Java EE 5 APIs:

    • Support for unified expression language
    • JSF 1.2: SpringBeanFacesELResolver
    • Consistent use of JSR-250 annotations
    • JTA 1.1.: support new
    • TransactionSynchronizationRegistry
    • new JTA, JavaMail and JAX-WS support also available for stand-alone usage

    Spring 2.5 also supports the Java Connectivity API (JCA)

    Other J2EE ehnancements that come with Spring 2.5 include:

    • Spring 2.5 officially supported on IBM WAS 6.x
    • WebSphereUowTransactionManager
    • WebSphereTransactionManagerFactoryBean replacement
    • no new features, but uses supported IBM API

    Spring 2.5 also works well with OSGI. it provides a dynamic module system and is bundled as central packaging unit.

    It also supports new configuration features such as annotations-driven configuration, JMS and JCA support, enhanced AspectJ support and annotations-driven MVC controllers.

    Spring 2.5 embraces annotations. It supports JSR250 annotations and Spring specific annotations (makes the code spring dependent). This doesn’t mean that they prefer annotations to XML, XML is in no way deprecated. Spring specific annotations can be used if you need more power than the traditional annotations, and also if you don’t care about migrating your application to another framework):

    • New @Autowired annotation
      • autowiring by type
      • of fields methods and constructors
      • AutowiredAnnotationBeanPostProcessor
    • Autowiring by type might have too many candidates
    • provide hints using qualifiers
    • through new @Qualifier annotation
    • on fields or parameters

    Annotations-based autowiring pros and cons

    • pros:
      • self-contained: no XML configuration needed
      • work in much more cases than generic autowiring (ant method or field)
      • JSR 250 or custom annotations keep your code from depending on Spring
    • cons:
      • requires classes to be annotated
      • configuration only per class not per instance
      • changes require recompilation

    At this point they presented a demo demonstrating the the pet clinic and showed the capabilities of spring.

    Spring 2.5 also provides extra support for AspectJ

    • new bean(name) pointcut element
      • for use in aspectj pointcuts
      • matches beans by name
      • supports wildcards
    • no more need for BeanNamedAutoProxyCreator
    • support AspectJ load-time weaving through spring’s LoadTimeWeaver
    • driven by META-INF/aop.xml files
    • for any supported paltform
      • generic spring vm agent
      • various app servers: Tomcat, Glassfish, OC4J

    You can use AspectJ to inject instances of objects that have not been constructed by Spring.

    Since we are not using proxies any more but AspectJ, we can apply aspects that we were not able to do it before. We don’t have to force everyone to go through the proxy instead of the real object. The programme becomes more natural.

    Spring has its own web framework, the Spring MVC, which in Spring version 2.5 it has

    • Java5 variant of MultiActionController
      • including form handling capabilities
    • POJO based
      • just annotate your class
      • works in Servlet and Portlet container
    • Several annotations
      • @Controller
      • @Requestparam
      • @RequestMapping/@RequestMethod
      • @ModelAttribute
      • @SessionAttributes
      • @InitBinder

    The test context framework

    • revised-annotation based test frameworks
    • supports JUnit 4.4, TestNG as well as JUnit 3.8
    • supersedes older JUnit 3.8 base calsses
      • AbstractDependencyInjetionSpringContextTests and friends
      • they’re still there for 1.4
      • will be deprecated in Spring 3.0
    • convention over configuration
      • use only annotations
      • reasonable defaults that can be overridden
    • consistent support for spring’s core annotations
    • spring-specific integration testing functions
      • context management and caching

    Another pet clinic demo of spring followed at this point.

    Profiler: the better debugger (by Heiko Rupp)

    This was a very similar talk to the one Kirk and Holly gave this morning. Nothing new really here (I shouldn’t have gone but since I got in the room and I thought I’d stay).

    Main points I wrote down:

    A debugger is a tool that steps through code, can look at variables, stop/.pause the programme on exception or breakpoints. But there are issues with time-outs in larger applications.

    A profiler analyses the CPU and memory usage. The application runs while profiling and there is no view on content of the variables. Free profilers, NetBeans profiler, Eclipse TPTP, commerical profilers: JProfiler, JProbe.

    Why use a profiler for debugging?

    • start of call chain is unknown
    • call stack uses reflection
    • use of big complex frameworks
    • transaction timeouts render values invalid in the debugger

    And then a NetBeans profiler demo followed.

    Categories: devoxx
    1. No comments yet.
    1. No trackbacks yet.

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out /  Change )

    Google photo

    You are commenting using your Google account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s

    %d bloggers like this: