Then I headed to the the Guice BOF, which was a fun crowd. They talked about the upcoming Guice 2.0 and the interesting new features. Unfortunately, I’ve only played a bit with Guice so I can’t say that I found it personally meaningful, but it sounded like some good stuff. I thought the idea of using custom annotations was interesting. Plus they had copious quantities of beer.

Then it seemed like that whole crowd migrated en masse to the Java Posse BOF (also beer enabled from Atlassian). The Java Posse do a podcast of Java news of course and this was a live episode. They took a bunch of polls of the audience. Given the exuberant crowd, I’m not sure how much you can draw from the responses. :)

Some little tidbits that they threw out that I found interesting.

• Scala is the new Java - I know the posse love the Scala and I think it’s an amazing language but I’m just not seeing it as the “new Java”.
• Kindle runs Java - I guess it was unknown before that the new Kindle e reader device from Amazon runs Java (on Linux). Pretty cool
• What is Duke? - there was a brief discussion of what the Java mascot actually is. Someone said it’s based on the shape of the communicator device in Star Trek. None other than Josh Bloch said “Duke is the bastard child of a scrubbing bubble”. Sounded like an authoritative source to me.

I asked a question and got a free copy of the new Effective Java at the BOF, which I am quite happy about.

Overall a fun night! (I don’t think Smashmouth could have competed.)

I mentioned that another case of this I’ve experienced is playing viola in a quartet. You are very intensely aware of what the other three people are doing (even though that may be evident externally) and you are all trying to accomplish the same thing. It’s exhilarating in a very unique way.

Of course, sex is another good example of shared flow state. :)

Anyone have any others?

So far the benefits I’ve seen from using Twitter:

1. News - I see links and news of interest to me faster than I do via blogs and feeds. Twitter is an amplifier. If the people you follow share your interests, anything popping from there is far more likely to be interesting to you than the average blog entry. I’m a blogaholic and I’ve almost stopped reading blogs in the last couple weeks yet feel more connected.
2. Breadth - I’ve casually met a lot of people through Twitter due to common friends that I never would have met otherwise.
3. Depth - You can actually twitter someone that you don’t know well and end up having lunch with them. Or you can just twitter out loud and someone will find you. This is particularly useful in cases where there are large congregations of people with similar interests like conferences, but probably useful anywhere.
4. Serendipity - I’ve been able to talk to users of our products due to posts on Twitter and that was really cool. There’s no way I would have had that interaction otherwise.

I do understand that Twitter is not for everyone. But so far I’ve enjoyed it. I don’t know if Twitter will survive or not but I think microblogging will in some form.

Everyone is quite familiar with the fact that other languages can be compiled to bytecode and the JVM can be reused as runtime on the bottom part of the stack. Geert’s talk was about the top half however.

He focused on four technologies all of which use Java unmodified at the top but do fun things in the middle or bottom layers:

1. Terracotta - extends the semantics of normal Java concurrent programs to spread heap objects and coordination across a cluster of JVMs. In this case Terracotta hits the middle third by transforming the bytecode. The runtime is used unchanged.
2. RIFE - implements continuations to alllow “save game” and “resume game” semantics to your web conversations. I loved the game analogy and the audience liked it too. This is done again through bytecode modification in the middle tier with an unchanged runtime.
3. Android - Android is Google’s development environment for mobile apps. It uses normal Java language and even compiles to byte code, but then transforms that byte code into a different byte code to run on a different VM entirely - the Dalvik VM.
4. Google Web Toolkit - GWT allows you to write web apps in Java, then compiles the Java source into Javascript, thus completely replacing both the byte code AND the runtime.

In all, this was a very fun talk and makes an important point about Java-the-language being every bit as important as Java-the-VM.

In late breaking news, Geert will be repeating this talk Friday at 2:50 in Room 133 so you still have a chance to catch it if you want.

]]> http://tech.puredanger.com/2008/05/08/javaone-geert-bevin-on-java-as-api/feed/ http://tech.puredanger.com/2008/05/08/javaone-cliff-click-on-data-races/ http://tech.puredanger.com/2008/05/08/javaone-cliff-click-on-data-races/#comments Thu, 08 May 2008 17:32:44 +0000 Alex Java concurrency JavaOne http://tech.puredanger.com/2008/05/08/javaone-cliff-click-on-data-races/ Cliff’s talk focused on what data races are, why they happen, and how to debug them. A data race occurs when you have at least two threads accessing the same data and at least one of them is writing, and there is no ordering defined based on the Java memory model (by using synchronization, volatiles, Locks, etc). In this case, instruction reorderings can occur either in the hostpot JIT or in the hardware itself that will give you surprising results.

In fixing data races, a key thing to remember is that the memory barrier (synchronization, etc) must be present on all threads involved. If not, reorderings will still cause data races.

Cliff outlined the most common data races he sees:

1. Double read with write in the middle:

              T1                                          T2
   	if(p != null)
   							p = null
   		p.field
   

   This one is particularly nasty because on the left side, the read of p and the field actually will get done together in JIT’ed code most of the time so will show no issue. So, it only happens on infrequently used paths that happen to come under heavy contention. In other words, the NPE will show up just as a system comes under heavy load.

2. Two writes with read in the middle:

              T1                                          T2
   	size = size * 2;
   							array[size-1]
   	array = new[size]
   

3. Double-checked locking - horse.kill().beat()
4. Partial or no synchronization on data structures like HashMap - lots of subtle bugs if you believe you can use unsynchronized maps with single writer and cleverly catch exceptions

Cliff then went through tools for debugging data races:

• Visual inspection - current state of the practice, very slow, doesn’t scale, need an expert in both concurrency AND in the domain
• Printing / logging - make noise at each read/write of shared variable (but be careful about avoiding string construction). Use per-thread ring buffer. When error occurs, timestamp all buffers so you can reconstruct. Usually the offending thread will have been messing with the data just before the error occurred. This works but is very invasive.
• Tools - currently tools don’t scale into production. He did plug FindBugs as being able to detect many of the common data race problems (which matches my experience as well).

He mentioned some flags from the Azul VM that might be incorporated to the Sun VM at some point for helping to detect problems - one would autolock unsynchronized collections (since they rarely have contention), and another would throw an exception if racing in collections.

In general, this talk was weird as it had two possible audiences and probably didn’t serve either too well. Those experienced in concurrency probably could have gotten what they needed in 10 minutes. And those inexperienced were probably completely lost in the data flow analysis as he went through them really fast. As it was, he hit his talk summary about 25 minutes in and opened for questions at 30 minutes which seemed like some strange pacing.

]]> http://tech.puredanger.com/2008/05/08/javaone-cliff-click-on-data-races/feed/