Java Specialists' Java Training Europehome of the java specialists' newsletter

Newsletters related to Performance

Issue Subject Date
237 String Compaction
Java 6 introduced a mechanism to store ASCII characters inside byte[] instead of a char[]. This feature was removed again in Java 7. However, it is coming back in Java 9, except this time round, compaction is enabled by default and byte[] is always used.
236 Computational Complexity of BigInteger.multiply() in Java 8
BigInteger has new algorithms for multiplying and dividing large numbers that have a better computational complexity than previous versions of Java. A further improvement would be to parallelize multiply() with Fork/Join.
235 Checking HashMaps with MapClashInspector
Java 8 HashMap has been optimized to avoid denial of service attacks with many distinct keys containing identical hash codes. Unfortunately performance might degrade if you use your own keys. In this newsletter we show a tool that you can use to inspect your HashMap and view the key distribution within the buckets.
233 Intersection Types to give Lambdas Multiple Personalities
Lambdas are often described as anonymous inner classes without the boilerplate code. However, lambdas are more powerful. Firstly, a lambda does not always result in a new object. Secondly, "this" refers to the outer object. Thirdly, a lambda object can implement multiple interfaces. In this newsletter we will look at this third feature, where cast expressions use intersection types to produce lambdas with several interfaces.
232 ByteWatcher from JCrete
Even though standard Java is not real-time, we often use it in time-sensitive applications. Since GC events are often the reason for latency outliers, such code seeks to avoid allocation. In this newsletter we look at some tools to add to your unit tests to check your allocation limits.
217b Parallel Parking (Follow-up)
Heavily contended concurrent constructs may benefit from a small pause after a CAS failure, but this may lead to worse performance if we do more work in between each update attempt. In this follow-up newsletter, we show how adding CPU consumption can change our performance characteristics.
217 Parallel Parking
What is faster? Synchronized or Atomic compare-and-set? In this newsletter we look at some surprising results when we run Java on the new i7 chip.
195 Performance Puzzler With a Stack Trace
In this newsletter, we present a little performance puzzler, written by Kirk Pepperdine. What is happening with this system? There is only one explanation and it can be discovered by just looking at the stack trace.
193 Memory Usage of Maps
In this newsletter we measure the memory requirements of various types of hash maps available in Java. Maps usually need to be threadsafe, but non-blocking is not always the most important requirement.
191 Delaying Garbage Collection Costs
The garbage collector can cause our program to slow down at inappropriate times. In this newsletter we look at how we can delay the GC to never run and thus produce reliable results. Then, instead of actually collecting the dead objects, we simply shut down and start again.
187 Cost of Causing Exceptions
Many years ago, when hordes of C++ programmers ventured to the greener pastures of Java, some strange myths were introduced into the language. It was said that a "try" was cheaper than an "if" - when nothing went wrong.
183 Serialization Size of Lists
What has a larger serializable size, ArrayList or LinkedList? In this newsletter we examine what the difference is and also why Vector is a poor candidate for a list in a serializable class.
181 Generating Static Proxy Classes - 2/2
In this newsletter, we show how the Generator described in our previous issue can be used to create virtual proxy classes statically, that is, by generating code instead of using dynamic proxies.
180 Generating Static Proxy Classes - 1/2
In this newsletter, we have a look at how we can create new classes in memory and then inject them into any class loader. This will form the basis of a system to generate virtual proxies statically.
179 Escape Analysis
Escape analysis can make your code run 110 times faster - if you are a really really bad programmer to begin with :-) In this newsletter we look at some of the places where escape analysis can potentially help us.
174 Java Memory Puzzle Explained
In this newsletter, we reveal the answer to the puzzle from last month and explain the reasons why the first class sometimes fails and why the second always succeeds. Remember this for your next job interview ...
173 Java Memory Puzzle
In this newsletter we show you a puzzle, where a simple request causes memory to be released, that otherwise could not. Solution will be shown in the next newsletter.
170 Discovering Objects with Non-trivial Finalizers
It is well known that implementing a non-trivial finalize() method can cause GC and performance issues, plus some subtle concurrency bugs. In this newsletter, we show how we can find all objects with a non-trivial finalize() method, even if they are not currently eligible for finalization.
169 Monitoring Sockets
In this newsletter, we show two approaches for listening to bytes on sockets. The first uses the Delegator from our previous newsletter, whereas the second uses AspectJ to intercept the call to Socket.getInput/OutputStream. We also write an MBean to publish this information in JConsole.
165 Starvation with ReadWriteLocks
In this newsletter we examine what happens when a ReadWriteLock is swamped with too many reader or writer threads. If we are not careful, we can cause starvation of the minority in some versions of Java.
164 Why 0x61c88647?
Prior to Java 1.4, ThreadLocals caused thread contention, rendering them useless for performant code. In the new design, each thread contains its own ThreadLocalMap, thus improving throughput. However, we still face the possibility of memory leaks due to values not being cleared out of the ThreadLocalMap with long running threads.
158 Polymorphism Performance Mysteries Explained
In this newsletter, we reveal some of the polymorphism mysteries in the JDK. The HotSpot Server Compiler can distinguish between mono-morphism, bi-morphism and poly-morphism. The bi-morphism is a special case which executes faster than poly-morphism. Mono-morphism can be inlined by the compiler in certain circumstances, thus not costing anything at all.
157 Polymorphism Performance Mysteries
Late binding is supposed to be a bottleneck in applications - this was one of the criticisms of early Java. The HotSpot Compiler is however rather good at inlining methods that are being called through polymorphism, provided that we do not have very many implementation subclasses.
142 Instrumentation Memory Counter
Memory usage of Java objects has been a mystery for many years. In this newsletter, we use the new instrumentation API to predict more accurately how much memory an object uses. Based on earlier newsletters, but revised for Java 5 and 6.
135 Are you really Multi-Core?
With Java 5, we can measure CPU cycles per thread. Here is a small program that runs several CPU intensive tasks in separate threads and then compares the elapsed time to the total CPU time of the threads. The factor should give you some indication of the CPU based acceleration that the multi cores are giving you.
134 DRY Performance
As developers we often hear that performance often comes at the price of good design. However when we have our performance tuning hats on, we often find that good design is essential to help achieve good performance. In this article we will explore one example of where a good design choice has been essential in an effort to improve performance.
133 Safely and Quickly Converting EJB3 Collections
When we query the database using EJB3, the Query object returns an untyped collection. In this newsletter we look at several approaches for safely converting this to a typed collection.
130 Deadlock Detection with new Locks
Java level monitor deadlocks used to be hard to find. Then along came JDK 1.4 and showed them in CTRL+Break. In JDK 1.5, we saw the addition of the ThreadMXBean, which made it possible to continually monitor an application for deadlocks. However, the limitation was that the ThreadMXBean only worked for synchronized blocks, and not the new java.util.concurrent mechanisms. In this newsletter, we take a fresh look at the deadlock detector and show what needs to change to make it work under JDK 1.6. Also, we have a look at what asynchronous exceptions are, and how you can post them to another thread.
124 Copying Arrays Fast
In this newsletter we look at the difference in performance between cloning and copying an array of bytes. Beware of the Microbenchmark! We also show how misleading such a test can be, but explain why the cloning is so much slower for small arrays.
115 Young vs. Old Generation GC
A few weeks ago, I tried to demonstrate the effects of old vs. new generation GC. The results surprised me and reemphasized how important GC is to your overall program performance.
111 What is faster - LinkedList of ArrayList? 2005-07-12
105 Performance Surprises in Tiger 2005-03-28
098 References 2004-11-08
092 OutOfMemoryError Warning System 2004-07-20
090 Autoboxing Yourself in JDK 1.5 2004-06-22
088 Resetting ObjectOutputStream 2004-05-19
078 MemoryCounter for Java 1.4 2003-09-29
070b Multi-Dimensional Arrays - Creation Performance 2003-05-18
070 Too many dimensions are bad for you 2003-05-17
069b Results of last survey 2003-05-02
069 Treating Types Equally - or - Life's Not Fair! 2003-04-29
068 Appending Strings 2003-04-21
064 Disassembling Java Classes 2003-02-14
061 Double-checked locking 2002-12-07
060 Nulling variables and garbage collection 2002-11-29
059b Follow-up to Loooong Strings 2002-11-13
059 When arguments get out of hand... 2002-11-11
058 Counting bytes on Sockets 2002-10-09
054b Follow-up to JDK 1.4 HashMap hashCode() mystery 2002-08-15
054 HashMap requires a better hashCode() - JDK 1.4 Part II 2002-08-14
053 Charting unknown waters in JDK 1.4 Part I 2002-07-23
042 Speed-kings of inverting booleans 2002-02-23
038a Counting Objects Clandestinely 2001-12-28
038b Counting Objects Clandestinely - Follow-up 2001-12-28
029 Determining Memory Usage in Java 2001-08-28
027 Circular Array List 2001-08-02
024 Self-tuning FIFO Queues 2001-07-06
023 Socket Wheel to handle many clients 2001-06-21
016 Blocking Queue 2001-04-11
015 Implementing a SoftReference based HashMap 2001-03-28
001 Deadlocks
Java deadlocks can be tricky to discover. In this very first Java Specialists' Newsletter, we look at how to diagnose such an error and some techniques for solving it.

Extreme Java - Concurrency
Extreme Java - Advanced Topics
Refactoring to Java 8
Design Patterns
In-House Courses

© 2010-2017 Heinz Kabutz - All Rights Reserved Sitemap
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. is not connected to Oracle, Inc. and is not sponsored by Oracle, Inc.