The JVM finally moving forward

After almost a year of delay, Java 7 has been officially released for the Mac. SeeJava 7 Mac OS X download and README.

In order to use it in Eclipse and others, bear in mind that the PATH is now:

/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents

This may be inaccesible to Eclipse, but you can paste the whole line, or create a symlink. It contains the sources, but no Javadocs.

This is a huge milestone, which marks the beginning of the end for Java 6, which was released 6 years ago. Technologies like Scala have soared since. But now with JDK 7 been readily available in all platforms, and with many bugfixes since the original release, it's time to upgrade. Last step will be JDK7u6 when the JRE will be fully availabe. See my previous post on Java 7, 8 and beyond

Update: After running a couple of scripts, I ran into this issue with UnknownHostException in JDK7

See this snippet:

This is my /etc/hosts

127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%lo0 localhost
192.168.1.3 loki

Java 7, 8 and Beyond

Java 7 update 4 developer preview is available to download from OpenJDK website. Why is this any important? because is the first candidate release of the official JDK released by Oracle since Apple decided to stop shipping a custom build.

This also paves the way for further releases of Java 7 and ultimately Java 8 given the imminent end of life of Java 6.

Are you using Java 7 already? I can see it been similar to Java 5. Few people actually using it, and instead moving directly to Java 8, or feel pushed by it, to move into the last known stable version (in this case, 7).

Java 8 will bring lots of new features making the language a lot closer to what Scala delivers today, and is been heavily influenced by its success. See Simon Ritter's presentation and Fredrik Ohrstrom for more details. Better still... get yourself a build !

See Early Draft of Project Lambda by Brian Goetz. More info on Project Lambda for Java 8

More updates on Lambda, this time is on collections: Brian Goetz update on Streams for Java 8. I particularly like to stress this point on his blog post:

we will pursue an evolutionary strategy of adding extension methods to existing interfaces (such as Collection, List, or Iterable), or perhaps to new interfaces (such as 'Stream') that are retrofitted onto existing classes, enabling many of the desired idioms without making people trade in their trusty ArrayLists and HashMaps. (This is not to say that Java will never have a new Collections framework; clearly there are limitations with the existing Collections framework beyond simply not being designed for lambdas. Creating a new-and-improved collections framework is a fine candidate for consideration in a future version of the JDK.)

Even with Java8, Scala will continue to be ahead of Java, offering a more powerful and complete solution. The large change that was moving from Scala 2.7 to 2.8 in terms of upgrading collections, will have to wait at least until Java 9 to take effect. Because of this, Scala is a technology to stay, and lead the way to a functional revolution.

Understanding the JVM, concurrency and GC

A great collection of links and presentations on Java Virtual Machine and why understanding how it works is critical.

First, let's start with HotSpot, the default JVM. This is a mandatory intro into the responsibilities of the VM. Next, learning about the some of the most common optimizations that the JIT compiler has available, HotSpot FAQs, and method inlining

Now we are going to go down one abstraction layer, and jump into the hardware. A great presentation by Jevgeni Kabanov, by far the simplest to undestand: Do you really get Memory? I find this presentation a must see before jumping into the more hardcore versions that follow. In this talk, Jevgeni presents a simplified Java CPU model, showing the CPU, Memory, and more fundamentally, Caches.

Armed with this knowledge, we are then ready to take on the mammoth paper "What every programmer should know about memory by Ulrich Drepper. This is very low level at times, so worth watching Cliff Click's presentation: A Crash Course on Modern Hardware, which summarises it nicely.

Interesting article also on Memory Barriers and obviously, it wouldn't be complete without Doug Lea's concurrency in Java presentation. Always a good read, although really extensive, the Java Language Specification, Third Edition

Finally, I have reserved it for the last, Gil Tene's excellent Understanding Java Garbage Collection. Brings in lots of points that i didn't know about in my previous post The Art of GC Tuning. In particular, I really enjoyed the discussion around Application Memory Wall, and how our applications seem to range between 1-4 GBs, but rarely take advantage of increasing hardware power, and what are the main problems behind it. He shows how the Azul Zing VM can easily cope with 1/2 TB VMs without pausing.

That's quite a lot for now!

Exploring Scala Collections

This weekend I've been trying to write some microbenchmarks and discovered a large differences between different implements of the same problem: create a list of 10 million objects and print only the ones that are modulo of a million.

This is the code in question. It runs in 141 milliseconds requiring no more than 27 mbs JVM (the smallest i could create).

As shown in this StackOverFlow question, a range followed by a filter operation can even beat the performance of an array of primitives in Java. The space required is smaller, and the amount of time to execute it is barely comparable, whereas any other approach was in between one and two orders of magnitude worse, depending the case.

I learnt several things with this simple exercise, from Ranges, Array (compile to primitives, no need for Wrappers), and performance monitoring.

The costs of concurrency and the actor model

I was interested to understand more about how actors are implemented in Erlang. In an old but still relevant article, an argument is raised:

These days every third grader knows that processes are expensive. Ok, so we're not using real processes, we're using threads, but if you constantly create, destroy, and switch between thousands of threads you'll bring any system to a crawl. Threads are expensive for a number of reasons. They take a long time and a lot of memory to create because the operating system needs to set up many things (the stack, internal data structures, etc.) for them to work. They take a long time to destroy because all the resources they consumed need to be freed. And they take a long time to switch between because unloading registers, storing them, loading them back, and flipping the stacks is complicated business.

So how expensive it really is to create a Thread in java these days?

Peter Lawrey, writer of the excellent Vanilla Java blog, tell us that roughly, creating a Thread takes
about 70μ (microseconds), which is fairly expensive, but not prohibitive. The size of the stack can be configured by command line argument to the JVM, with a default of 512kb. According to some Mac OS X 10.5 docs, a thread takes about 90μ, which is kind of validates his results.

As it was pointed out in the StackOverflow discussion

Creating threads is expensive if you're planning on firing 2000 threads per second, every second of your runtime. The JVM is not designed to handle that. If you'll have a couple of stable workers that won't be fired and killed over and over, relax.

This is slightly different in Erlang, where everything is a Process, so the model leads you to that situation.

Essentially, Erlang uses a kind of lightweight processes, akin to green threads (VM scheduled pseudo-threads as opposed to real threads). Since they only consist of a mailbox implemented as a queue, it takes about 300 words to build one, meaning we can create thousands, even millions of them, so the only constrain is memory.

I read a great post on Erlang lightweight-process actor concurrency and it's inherent problems in terms of message passing costs, i.e., having to serialize the entire message between processes, even within the same node. The lack of zero-copy messaging between actors, even within the same node, can really hurt performance. It also talks a great deal on how the BEAM VM and HiPE JIT compiler aren't anywhere near as good as the industry leader JVM (or his favoured Azul Systems "pauseless" VM).

On that basis, after years of hardcore work on Erlang, he decants for Erjang (using Java's Killim actors) or Clojure, possibly
due to been more functional and lisp syntax. I wonder why Scala wasn't mentioned? Akka
offers the same principles of Erlang actors, but implemented in a much more robust way and running on top of the JVM.

Scala actors, particularly Akka actors, use configurableexecutors that efficiently reuse threads (and in Akka 2.0, this will be declaratively configured). Thus, i can see Akka
as supersiding Erlang, an the heir of the throne in actors concurrency.

The art of GC Tuning

Great presentation discussing best practices when tuning Garbage Collection on the JVM

The different GC Collectors:

Fragmented Heap:

See JVM GC tuning docs here

Also, a comparison of all the JVM GC implementations (particularly valuable given that Java8 will incorporate JRockit's features.

I've came across this links by reading the blog post on the new features of Cassandra 1.0. Some very interesting JVM tuning allowed them to increase performance manyfolds.

The JVM JIT compiler at runtime, and even the java and particularly scala compiler at compile time, love small methods that can be analysed in isolation. It is very important to consider the effect that the compiler can have whenever reading microbenchmarks.

Quoting Brian Goetz:

"Often, the way to write fast code in Java applications is to write dumb code -- code that is straightforward, clean, and follows the most obvious object-oriented principles."
Brian Goetz
Technology Evangelist, Sun Microsystems

For huge collections, is better to use a framework that can handle billions of items, potentially mapped outside of the heap, thus avoiding Full GC completely.