Cliff Click Jr.’s Blog's Blog
|
JavaOne JavaOne is fast upon us. It's a big year for Azul; we have 4 talks this year. I'm giving 3 and Gil Tene, our CTO, is giving the other one. I'm mentioning his talk specifically because it "sold out" and JavaOne kindly gave him a 2nd session in a new larger room at an earlier time - which will now be cavernously empty unless you sign up! The talk is very interesting (to me) - because it's essentially the GC version of "How NOT To Write A Microbenchmark" - it's full of specific advice on how to benchmark GC for large applications, and what traps to avoid when trying to write your own GC benchmark or testsuite. Some observations: SpecJBB2000 was originally intended as a Java middle-ware benchmark, yet was specifically designed so that GC never happened during the time portion of the run. Do you never see a GC cycle during the "timed portion" of your Java workloads? (SpecJBB2005 came about partially to correct this). <link to slides coming soon> Debugging Data Races is a re-run of a BOF I gave last year, but the material is more relevant that ever. Slides here. I had a number of comments from people who basically said "you shouldn't write datarace bugs in the first place" implying that (1) writing such bugs is Bad because they are so hard to find & fix, and (2) you wanted to write such bugs in the first place! My advice from last year still holds, and indeed I've got more evidence than ever that the bugs I'm targeting are the common bugs that bite you, and what I'm proposing is very accessible (no Phd required!). Towards a Coding Style for Scalable Nonblocking Data Structures is ... well, hopefully the title is fairly self-explanatory. I've talked this on this blog before; slides here. The basic idea is a coding style that involves a large array to hold the data (allowing scalable parallel access), atomic update on those array words, and a Finite State Machine built from the atomic update and logically replicated per array word. The end result is a coding style allowing me to build several non-blocking (lock-free) data structures that also scale insanely well. All the code is available on SourceForge. At this point I'm sore tempted to add transactions to the non-blocking hash table and essentially create an uber-data-grid. JVM Challenges and Directions in the Multi-Core Era is where Brian Goetz & I rant about the lack of any decent concurrent programming language. Slides here. Java's the obvious best State-of-the-Practice concurrent programming language, and there are plenty of better "academic toy" concurrent programming languages Out There. All right I'll stop before I start really ranting, but it's a topic I'm passionate about. Cliff Category: Web/Tech | | TrackBack (0) TrackBackTrackBack URL for this entry: Listed below are links to weblogs that reference JavaOne: CommentsRe: soapbox. I'm confused; I read that as saying "some languages avoid shared mutable state across threads" followed by "nobody avoids shared mutable state across threads"? Is it that Erlang, Scala, Fortress, X10, etc., are just not main-stream enough, or is it that their approaches still aren't what you have in mind? If the latter, is what you have in mind the stuff about your non-locking data structures? Or more than that? Inquiring minds want to know. :-) Posted by: Raoul Duke | May 1, 2008 1:20:46 PM Partly: Not main-stream enough, apparently for good cause. Maybe the new paradygm (no shared mutable variables) is the way to go, but then I can't code up e.g. my NonBlockingHashTable. Cliff Posted by: Cliff Click | May 1, 2008 1:41:08 PM I think a better model for those kinds of languages is are the lessons learned from RPC, where the external access is fundamentally marshaled away from the calling thread. RPC typically fell into the wrong solution space by attempting to shoehorn a fundamentally different paradigm into the old calling style; RPCs are inherently asynchronous and frequently have multiple return paths (which can be modeled as exceptional cases). With functional programming gaining traction, embracing that explicit asynchronicity can lead to the opacity of the underlying threading model. In my noodling around with Scala, I've found that the combination of strict adherence to the Law of Demeter and Scala's Actor messing pattern make for what should be very scalable code. Of course, then there's the gap between "should be very scalable code" and "very scalable code." :-) Posted by: Bob Hansen | May 2, 2008 6:49:07 AM I like the look of Scala, but I haven't played with the Actors model yet. This is a version of "no shared variables, use message passing" - which might very well be the Way To Go. I'm hoping to find a solution in the traditional shared-variable space, with language support getting the Mutexes in the right place (guarding the right accesses). At this point, I need an excuse to go do something larger and more real with Scala, to get a real feel for the flexibility & performance of the Actors. Cliff Posted by: Cliff Click | May 2, 2008 8:29:30 AM Cliff, The slides link for "Debugging Data Races" is the same as "JVM Challenges and Directions in the Multi-Core Era". Was this intentional? Asgeir Posted by: Asgeir S. Nilsen | May 3, 2008 12:27:45 AM Whoops, sorry! Corrected now. Posted by: Cliff Click | May 3, 2008 2:53:46 PM Maybe you should check out Clojure (http://www.clojure.org) and its use of thread-local vars. Not to mention the STM and agent system. Its aiming directly at improving concurrent programming. Posted by: xyz | May 23, 2008 2:21:51 AM Eeek! (Lots of ((Irritating, Spurious) (Parentheses)))! Performance in an STM is not transparent: it requires a runtime to do abort/retry, and as the runtimes get fancy & complex the behavior under load of STM's gets.... weird and unpredictable. Not something you can put into a production environment. But I *do* believe in strong control over the mutable shared variables - which you have. So: maybe. Cliff Posted by: Cliff Click | May 23, 2008 8:28:10 AM Post a comment |
Add to del.icio.us »
Digg this! »
Blogs that link here » 
