Thursday, September 25, 2008

There are two technical talks on V8 uploaded to YouTube. The first one is from Lars Bak who explains the key design decisions of V8 in a 5 minute talk. The other one is from Kevin Millikin who goes into more detail on Google Chrome and V8.

Tuesday, September 9, 2008

There's an odd misconception in the computing world that writing compilers is hard. This view is fueled by the fact that people don't write compilers very often. People used to think writing CGI code was hard. Well, it is hard, if you do it in C without any tools.

Sunday, September 7, 2008

Seems like this is a popular meme on the Internet. To humor my friend Wille, here are my answers to this thingy.

How old were you when you started programming?

I think I was around 10 or 11 years old when I first started out programming. But I actually stopped doing that for a year or two because I was so convinced I wasn't going to be any good at it. I think I was 14 years old or so when I started programming "seriously."

How did you get started programming?

I'm not sure. We got a PC home in the beginning of 1990s and soon enough I was "hacking away" with GW-BASIC that came with MS-DOS. Why? I have no idea. Probably because it was a lot of fun.

What was your first language?

GW-BASIC.

What was the first real program you wrote?

I'd say xmlindent. It's the only program I've written mostly by myself that has actual users.

What languages have you used since you started programming?

C and Java. I've ventured into C++, Ruby, Perl, Visual Basic, and Erlang along the way but I can't claim any expertise on them.

What was your first professional programming gig?

I started working for a small software company few weeks before turning 18 in the summer of 2000.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Don't work in isolation. Software development is mostly about working together with other people and open source projects are a great way to learn how to do that. So instead of working alone on piece of code that no one else will ever see, read code written by others and try to improve it while engaging in discussions on the project mailing lists. It's an experience you won't regret.

What’s the most fun you’ve ever had programming?

Having the first few patches accepted to the mainline Linux kernel back in 2005.

If you're interested in virtual machines and compilers, you've probably already read all about Google's new V8 JavaScript Engine. But what you might have missed is that the V8 team has many people from the original HotSpot team on board. For those who are not familiar with the history of the JVM, the first VM to optimize execution time with Just-in-time compilation techniques, HotSpot, emerged from Strongtalk, a VM that focused on delivering high performance for Smalltalk. Strongtalk used many innovative optimizations originally developed for the Self programming language that is characterized as one of the most dynamic language ever designed (and thus painful to generate efficient machine code for).

The V8 JavaScript Engine uses some of the same techniques developed for the Self programming language to improve JavaScript execution time. One of the core optimizations is is a pretty neat trick to improve access times to properties of an objects that can dynamically gain new properties at run-time. The idea is pretty simple: V8 doesn't need to resolve a property for every access because it generates hidden classes in the background and can thus generate better code because the properties are always at known locations. Whenever a new property is added to an object, the hidden class is updated. Furthermore, with these hidden classes, V8 can also use other class-based optimizations such as inline caching to speed up execution time even more.

It's going to be interesting to see if HotSpot will also get some of the same optimizations as V8 (if it already doesn't have them) now that Sun is working towards better support for dynamic programming languages such as Ruby and Python on the JVM.

Tuesday, September 2, 2008

Jato now supports 57% of the JVM instruction set on 32-bit x86! Bulk of the new supported instructions come from Arthur Huillet's 64-bit arithmetic operations work and rest of them are branch bytecode instructions added by me and Saeed Siam. Arthur has been working on proper infrastructure to support 64-bit arithmetic operations for a long time. With commit 420686e ("x86: split binop_reg_local in binop_reg_local_low and binop_reg_local_high for 64bit arithmetic") we finally had everything in place to implement the actual bytecode instructions.

We've actually had support for 64-bit addition in tree for a while now (just not enabled), so after we nailed down the lcmp bytecode (that turns out to be hard on 32-bit which is why we cheated a little bit) in commit 30e6202 ("jit: Added emulation function for lcmp. Used on x86 architecture.") all Arthur had to do was add LongArithmeticTest regression tests and we had coverage for ladd and bunch of related long type bytecodes such as lload and llstore (with all their variants). Arthur also sent patches for many of the other long arithmetic operations leaving just lmul, ldiv, lrem, lshl, lshr, and lushr unsupported. Of course, we don't support the int to long (and vice versa) conversion bytecodes yet either.

The new branch bytecode instructions were added by commit cd2ba2a ("x86: add support for if_icmp{eq,ne,lt,gt,le,ge} bytecode instructions"). The instructions were low-hanging fruits, really, but we need most of them for System.out.println() so it's a big improvement. Unfortunately we seem to have introduced a regression in the spill/reload code so the tests fail earlier for the System.out.println() test than before. There are also some register-to-register int arithmetic instruction selector rules missing so there's still more work to do here.