Category: Work

Roo in Japan

I was in Japan last week for business.  While we had been talking about the possibility of going for a while, I found out less than 24hrs before getting on a plane (Jenn was very understanding).  This was my first time across the Pacific Ocean, and with a 14hr leg (single flight) in my trip, I set a new personal record for being stuck on a plance (in economy no less).  The time delta was 14hrs meaning that at 7am in Japan, it was 5pm the previous day at home.

I was staying in Tokyo, near Shinjuku at the Hyatt Regency.  It turns out this was very close to the Park Hyatt that was featured in the movie Lost in Translation (which if you haven’t seen, is a good movie).  The Hyatt was a nice hotel, certainly meeting western standards for space.

Since I was there for business, I was a little concerned about making the right first impression.  I found a few links that helped me not feel like a total idiot.  Generally the Japanese people feel very polite, the bowing really struck me.  The general care they take presenting you with a bill is quite nice, it is done similar to the business card exchange which is very ritualized.

Thankfully, the company we were visiting is a little less traditional and tends to style itself after a Silicon Valley business.  One thing that I would try to do for another trip is make sure I have a few small token gifts from Canada to share with my hosts.

Since the employees of the company were Japanese, we were using a translator.  While some of them did speak English, there was a varying level of abilty with the language.  Since I don’t speak any Japanese the translator was a huge help.  Anyone who has head me speak knows how quickly I can go – this won’t work with a translator.  It took some getting used to, breaking ideas down into short snippets that could be translated without losing any of the technical content (just because they don’t speak the same language, doesn’t make them simpletons).

On day 3 I noticed that the translator was fixing my errors in naming folk by adding -san,  and I was honoured to hear Andrew-san a number of times.  I’ll go out on a limb a little here as I don’t know, but it also seemed to take a little time to break down some of the trust barriers – this may be a cultural issue, or just the standard technical problem of everyone is an idiot until proven otherwise.  By the afternoon of the 3rd day we were all jamming at the whiteboard discussing issues, and it was clear that there was understanding (both ways) even without translation.

We had dinners out as a group (without the translator) and there were enough folks with both English and Japanese on both the customer and IBM side to help things go smoothly enough, they were also especially helpful in instructing us how to eat dinner as many of the dishes were unfamiliar.  We ate in restaurants with low tables but with a cut-out below for your legs, we also removed our shoes before entering the eating area.  While the food was unfamiliar, it was all good. My best guess after the fact is that the meal was ichijū-sansai style.  The soup was cooked at the table and I couldn’t help but compare it to a DIY meal such as fajitas (which I always want a discount on as I’m doing part of the worK).

It was cool to see that Bunnie was in Japan at the same time, and blogging about both food and some of the neat things to see in Japan.  Unfortunately I didn’t have time to explore some of the things he talked about, but it did help me get my head around the culture a little more.  In the little time I did have free, I did a little souvenier shopping – while I could navigate the subway and the stores, the language barrier was significant. Unfortunately I didn’t manage to find a 100 yen shop (dollar store), but did explore a few of the 10+ story department stores.  I ended up buying a few things at a shop on the 45th floor of the Tokyo Metropolitan Government Offices  which gives an amazing view of the city.  In the elevator ride down it was a pretty tight right with about 8 other people, but none of them were above the level of my shoulder – Japan isn’t built for people who are 6 feet tall.

I had been told that McDonald’s was “the same, but not the same – you have to try it”.  The menu certainly had some unfamiliar selections on it such as Ebi Filet-O (shrimp burgers).  When I got to the airport the food selection was pretty limited but there was a McDonald’s so I figured why not?  The double Big-Mac and fries, tasted the same (or possibly better) than the ones I’m used to.  I did also eat out of one of the ubiquitous vending machines, the ice cream was very good.

While I was there the weather was mostly overcast, but around 10C to 15C.  During the day I’d forego having a jacket which made me stand out in crowds.  Generally the Japanese were bundled up in jackets as it was considered “cold”, but as I was primarily in the office (24C), subways and stores I found it hot if I had a jacket on.  It did cool off in the evenings, and many of the commuters had very long trips (1hr+) which might have required more variation in clothing.  In the evenings I did wear a jacket, I’m Canadian – not crazy.

It was a good trip, but I’m really glad to not be on a plane and staying close to home for a while.

Java Performance in 64bit land

If you were buying a new car and your primary goal was performance, or more specifically raw power – given the choice between a 4 cylinder and a 8 cylinder engine, the choice is obvious. Bigger is better. Generally when we look at computers the same applies, or at least that is how the products are marketed. Thus a 64bit system should out-perform a 32bit system, in the same way that a quad core system should be faster than a dual core.

Of course, what a lot of the world is only starting to understand is that more isn’t always better when it comes to computers. When dealing with multiple CPUs, you’ve got to find something useful for those extra processing units to do. Sometimes your workload is fundamentally single-threaded and you have to let all those other cores sit idle.

The 32bit vs. 64bit distinction is a bit more subtle. The x86-64 architecture adds not only bigger registers to the x86 architecture, but more registers. Generally this translates to better performance in benchmarks (as having more registers allows the compilers to create better machine code). Unfortunately until recently, moving from a 32bit java to a 64bit java mean taking a performance hit.

When we go looking at java performance, there are really 2 areas of the runtime that matter: the JIT and the GC. The job of the JIT is to make the code that is running execute as fast as possible. The GC is designed to take as little time away from the executing of code as possible (while still managing memory). Thus java performance is all about making the JIT generate more optimal code (more registers helps), and reducing the time the GC has to use to mange memory (bigger pointers makes this harder).

J9 was originally designed for 32bit systems and this influenced some of the early decisions we made in the code base. Years earlier I had spent some time with a PowerPC system that ran in 64bit mode trying to get our Smalltalk VM running on it, and had reached the conclusion that the most straight forward solution was simply to make all of the data structures (objects) twice as big to handle the 64bit pointers. With J9 development (circa 2001), one of the first 64bit systems we got our hands on was a Dec Alpha so we applied the straight forward ‘fattening’ solution, allowing a common code base to support both 32bits and 64bits.

A 64bit CPU will have a wide data bus, but recall that this same 64bit CPU can run 32bit code as well and it still has the big wide data bus to move things around with. When we look at our 64bit solution of allowing the data to be twice as big, we’re actually at a disadvantage relative to 32bits on the same hardware. This isn’t a problem unique to J9, or even Java – all 64bit programs need to address this data expansion. It turns out that the dynamics of the java language just tend to make this a more acute problem as java programs tend to be all about creating, and manipulating objects (aka data structures).

The solution to this performance issue is to be smarter about the data structures. This is exactly what we did in the IBM Java6 JDK with the compressed references feature. We can play tricks (and not get caught) because the user (java programmer) doesn’t know the internal representation of the java objects.

The trade off is that by storing less information in the object, we limit the total amount of memory that can be used by the JVM. This is currently an acceptable solution, as computer memory sizes are nowhere near the full 64bit address range. We only use 32bits to store pointers, and take advantage of 8 byte aligned objects to get a few free bits [ pointer << 3 ]. Thus the IBM Java6 JDK using compressed references (-Xcompressedrefs) can address up to 32Gb of heap.

We’re not the only ones doing this trick, Oracle/BEA have the -XXcompressedRefs option and Sun has the -XX:+UseCompressedOops option. Of course, each of the vendors implementations are slightly different with different limitations and levels of support.  Primarily you see these flags used in benchmarking, but as some of our customers are starting to run into heap size limitations on 32bit operating systems they are looking to move to 64bit systems (but would like to avoid giving up any performance).

There is a post on the websphere community blog that talks about the IBM JDK compressed references and has some pretty graphs showing the benefits. And Billy Newport gives a nice summary of why this feature is exciting.

Retrospective

I’ve decided to start including work related items in my blog here.  Please view the About page to see the standard disclaimer.  A fair number of the things I do at work can’t be discussed in public until they arrive somewhere in product form, by then they usually feel like old news to me and often information has been leaked via other channels.  Thus, some of the work related posts might seem a little boring to those “in the know” but I hope to help people put 3+4 together by linking to various bits of information, or simply provide a “straight from the developers” viewpoint.  I guess we’ll see how it goes, requests and feedback are welcome.

Recently Rick DeNatale posted a nice personal history of Smalltalk, I’m quite proud to have been part of building several of the products he mentions.  The OTI VM team started out building Smalltalk, but moved on to Java by first doing VisualAge for Java, followed by J9 for embedded.  Currently we still actively develop J9 which is primarily used as the core of the IBM JDK, but we still do embedded work as well as a Real-Time Java offering.