Talk is Cheap…

Been busy this month getting talks together.

 

First up: MSPC08, Workshop on Memory Systems Performance and Correctness.  I got my IWannaBit! paper accepted.  In this paper I propose a single hardware Bit; one that tracks L1 misses & evicts.  Using this one bit I can prove atomicity of a series of operations, or take corrective action if the operations are not atomic.  I basically can convert a hardware stall/fence for memory ordering into a software spin loop (plus I get to do other things while I’m waiting on the hardware).  It’s a pretty cool notion, half-way to Transactional Memory and half-way to DCAS but with almost no hardware (and replaces either LL/SC or CAS ta-boot!).

 

Next I submitted 4 talks to JavaOne, and amazingly these 3 got accepted:

  • JVM Challenges and Directions in the Multicore Era – This is where I rant against all our current concurrent programming models.  Concurrent programming is very hard, and most of the currently debated solutions (e.g. transactional memory, atomic, locks, threads) does NOT address the hardest part of writing concurrent code.
  • Debugging Data Races – given as a BOF to last years JavaOne.  I’ll freshen up the slides but mostly cover the same ground.
  • Toward a Coding Style for Scalable Nonblocking Data Structures – This the notion behind my NonBlockingHashTable taken to extremes.  Again, these slides  are old but start in the right direction: the JavaOne talk will “up level” the discussion and apply the same techniques to several different datastructures.

 

I’ll probably be speaking at TSS Las Vegas again this year, but I haven’t a clue about what!     🙂

 

More cheap talk: I think I’ve figured out how to do all the key bits for a full-blown in-memory DB: atomicity (nobody sees partial updates), non-blocking (no deadlocks; always some transaction can make progress), probably even fair (everybody’s transaction gets to complete eventually, no matter the size or conflicts).  And fast: I bet I can sustain > 100million (simple) DB ops/sec.  Larger transactions will take longer of course.  Of course, it’s all in-memory so the usual notion of durability is limited to the up-time of the server (it’s actually not that bad: I can still checkpoint slowly to disk so e.g. the disk is no more than 60sec out-of-date and is still coherent (represents some snapshot of the real DB)).

 

Enough Cheap Talk!  I need to get busy making slides…

 

Cliff