Java Extreme Performance: Part 2 – Object pooling

This is the second in the series about extreme Java performance; see Part 1 for more information.

In most cases creating objects is not a performance issue and object pooling today is considered an anti-pattern. But if you are creating millions of ‘difficult’ objects per second (so ones that leave a stackframe and potentially leave a thread) it could kill your performance and scalability.

In Multiverse I have taken extreme care to prevent any form of unwanted object creation. In the current version a lot of objects are reused, e.g. transactions. But that design design still depends on 1 object per update per transactional object (the object that contains the transaction local state of an object; I call this the tranlocal). So if you are doing 10 million update transactions on a transactional object, at least 10 million tranlocal objects are created.

In the newest design (will be part of Multiverse 0.7), I have overcome this limitation by pooling tranlocals when I know that no other transaction is using them anymore. The pool is stored in a threadlocal, so it doesn’t need to be threadsafe. To see what the effect of pooling is, see the diagrams underneath (image is clickable for a less sucky version):

without pooling
with pooling

As you can see, with pooling enabled it scales linearly for uncontended data (although there sometimes is a strange dip), but if pooling is disabled it doesn’t scale linearly.

Some information about the testing environment:
Dual cpu Xeon 5500 system (so 8 real cores) with 12 gigs of ram and I’m using Linux 64 bit/Sun JDK 1.6.0_19 64 bits and the following commandline settings:java -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:+UnlockExperimentalVMOptions -XX:+UseCompressedOops -server -da

The new diagram without smooth lines. Unfortunately I was not able to generate a histogram in a few minutes time (image is clickable).

7 Responses to Java Extreme Performance: Part 2 – Object pooling

  1. Seun Osewa says:

    Hello Peter,

    Interesting topic. The shape of your graph is … unlikely, though. I find it difficult very difficult to believe that smooth but irregular sine wave pattern is actually possible!

    Can you indicate the actual data points? And also provide the code you used? We may be able to analyze the results further.


  2. pveentjer says:

    Hi Seun,

    The pretty sinus was created by configuring some line smoothing in gnuplut.

    I’ll create a new diagram (combining both) that uses straight lines between the points.

    I’m not going to release the code yet, will only be done after the 0.6 release.

  3. ad says:

    Line smoothing is useless for this diagram.
    Your X-axis dimension is the number of threads. It is a discrete set of values. You cannot have 2.4 threads for instance. You have 2 or 3.
    A bar chart would be a more appropriate way to visualize it.

  4. Seun Osewa says:

    Hello Peter. Thanks for the new diagram.

  5. Chris Vest says:

    That is an impressive difference.

    The dip at the seventh test looks like an out-lier. I wonder if it reproducible. The JIT sometimes chooses to equal executions optimize differently, whereby “equal execution” I mean the same code doing the same things with the same data. I recall that a study found that one in five start-ups of a JVM would produce sub-optimal JIT’ing of their benchmarks.

  6. […] engine: a new STM engine has been added that is better scalable and better performing than the current TL2 (MVCC) based engine. There are 2 reasons for this: much more object pooling […]

  7. Maninder says:

    It would be interesting to see the actual pool sizes of the threads during execution.
    Can you please point me to the object pool package in your source?
    I am interested to see
    1. What is the behavior of the pool if a user requires more objects than the max pool size?
    2. If the pool size grows, does it shrink also? What is the algo for pool shirking.

Leave a Reply to pveentjer Cancel reply

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

You are commenting using your 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: