Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

We’re showing branches in this repository, but you can also compare across forks.

base fork: atoulme/atoulme.github.io
base: 15c9a6e08f
...
head fork: atoulme/atoulme.github.io
compare: 7f69bfb70c
  • 2 commits
  • 2 files changed
  • 0 commit comments
  • 1 contributor
62 _posts/2011-11-24-jvm-and-moores-law.textile
View
@@ -0,0 +1,62 @@
+---
+layout: post
+title: JVM and Moore's Law
+---
+
+*Note*: this post tries to present and explain a few tweets observed in the wild. Clearly, there may be inadequacies or missing items in this analysis, which you are welcome to point out. Please read this as a discussion, not a rant.
+
+!/images/rtomayko-mri-github-enterprise.png(We moved from JRuby to MRI with GitHub Enterprise. No offense, just that GitHub is a Unix application.)!:https://twitter.com/#!/rtomayko/status/131468168634974210
+
+Ryan's tweet is very interesting in this time and day. By the way, it indeed says nothing wrong about JRuby - everybody loves JRuby and the kind folks behind it for their high level of support and commitment.
+
+The problem boils down to the architecture implied by the JVM and the way pieces move in web backends.
+
+But let's back up a bit: Ryan is talking about Github being a Unix application. What does that mean ?
+
+Well, first of course, that the program runs on Unix only, any flavor (Mac or Ubuntu) being eligible. It also encompasses the way the program will run and be administered.
+The main reason Ryan points out is the use of sockets and file selectors, using the full power of the "Unix platform":https://twitter.com/#!/rtomayko/status/131519980071174145.
+
+There is a strong revival of the "Unix philosophy":http://en.wikipedia.org/wiki/Unix_philosophy driving this move, which can be oversimplified by "creating a program that does one thing well":https://twitter.com/#!/rtomayko/status/131469814093979649.
+
+MRI stands for "Matz's Ruby Interpreter". It is a C-based implementation of the Ruby language.
+
+h2. Where is the JVM shining ?
+
+First, it was a good idea to use the JVM when Windows mattered. That never really was a big constraint for web development, but there was an age where Windows was more popular amongst developers, and is still used quite a lot in development shops (the ones in China and India for example). For more debate on that, you can read this "post":http://teddziuba.com/2011/03/osx-unsuitable-web-development.html by Ted Dzubia, the paragraph on "You don't deploy to BSD".
+
+The JVM has broken ground by developing a great memory model and allocation. That by the way goes for any Virtual Machine approach to running software (hello LLVM and Rubinius!). The idea is that the software will optimize running the code by caching data and even, with Hotspot, compile the code into native blocks. The garbage collection is done asynchronously to remove stale dereferenced objects.
+
+The JVM is very good at spawning threads, for parallel processing. As a point of comparison, MRI (1.8) doesn't do threading as well. The threads MRI create are called "green threads":http://en.wikipedia.org/wiki/Green_threads.
+
+bq. In computer programming, green threads are threads that are scheduled by a virtual machine (VM) instead of natively by the underlying operating system. Green threads emulate multithreaded environments without relying on any native OS capabilities, and they are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support
+
+MRI 1.9 does bring support for real threads. It is known though that a number of libraries written in Ruby don't support multithreading correctly (that, by the way, is a problem for JRuby too).
+
+There are ways to extend the link to the platform the JVM runs on by creating Java Native Interfaces (JNI). Most of the POSIX support of JRuby is done via "JFFI":https://github.com/wmeissner/jffi. Most of the file level support for JRuby binds to this, for things made available via the Kernel class (think chmod).
+
+There is innovation in the JVM space, with the upcoming Java 7 release which will bring "significant gains to the dynamic languages using it":https://api.twitter.com/#!/headius/status/55697023952883712 (more info on this "blog post":http://blog.headius.com/2011/08/jruby-and-java-7-what-to-expect.html). For the time and effort it took to bring the new lambda feature to light, Raganwald developed a brilliant analysis "here":http://raganwald.posterous.com/javas-comb-over. It's worth noting that innovation on the JVM never stopped - all the JDK 6 updates brought significant changes and performance optimizations to Hotspot for example.
+
+h2. Serving HTTP requests from MRI or Java ?
+
+If you serve HTTP requests from Java, your JVM receives all requests and the web server forks a thread for each request. The threads run in parallel in the same memory space and your application acts as a multithreaded app.
+
+There are many web frameworks in Java (I personally have a crush for Jetty, the team absolutely rocks :)), but the point is that they will want to get access to the sockets directly. If you are familiar with the Unix world, you will find disturbing the way Java apps take over sockets directly with Axis2, Camel, Jetty or Tomcat.
+
+If you serve HTTP requests with MRI, the requests are passed via middleware to a set of processes, each of them serving a request. Each process is spawn from the application. This is the model used before by PHP or CGI applications.
+
+In that model, there is no concurrency, but also no memory shared between two instances, so you might end up loading twice the same data from the database. The middleware can be Apache or Nginx, and may go through proxying and Mongrel, or using Passenger.
+
+h2. What are both approaches best at ?
+
+With MRI, the web request has more chances to be served, since it’s easier to manage a set of workers, killing the ones that go overtime.
+
+With Java, the application lifecycle management and the cached data is better utilized, so Java apps do a good job at cubing data with Hadoop (see this "awesome presentation":http://www.sfjava.org/events/16341675/?eventId=16341675&action=detail for more insights). Threads can get stuck though, and you can go into strange states if you hit a OutOfMemoryError.
+
+h2. What is the field going to look like on the long run ?
+
+The JVM has big legal challenges coming up with the Android litigation. It is also bound to Oracle, which may have items in the agenda that might not work best for others. But maybe this is just FUD.
+
+To me, it looks like "Moore’s law":http://en.wikipedia.org/wiki/Moore's_law and virtualization play in favor of Ruby. A bunch of workers can respawn easily, and use the hardware at best it can. You can tell I’m seduced by this Unix application paradigm. On the flipside, more memory can help Java hold on to more objects and do more processing in the background.
+
+*tl;dr:* Java is good at multithreaded apps, Ruby MRI has good tooling to serve reliably HTTP requests. Pick the right tool for the job.
+
BIN  images/rtomayko-mri-github-enterprise.png
View
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

No commit comments for this range

Something went wrong with that request. Please try again.