February 12th, 2008
Been busy this month getting talks together.
January 12th, 2008
I Hate Makfiles....
January 7th, 2008
I went to the winter meeting of DaCapo, a small group of senior academics and industrial scientists mostly focussed on GC & Memory-related issues (but with fairly wide interests). Much of the work is not yet published; work-in-progress stuff (lack of rigorous experiments, or badly broken implementations, or Big-Ideas-No-Code state, etc). So I won't repeat what I saw here directly, contact the authors directly if you're interested in something. The DaCapo
December 12th, 2007
I've been busy at work, but it's been awhile so I've got a collection of odds-n-ends I've been meaning to write up: Bandwidth: 70Gb/sec A 768-way Azul (7280 box) gets 70Gb/sec of throughput as measured with a multi-threaded pure Java version of the infamous STREAM benchmark. Not official (since it's neither C nor FORTRAN!), so don't quote me on this but it does put our gear in the top-20 highest-bandwidth supercomputers.
November 6th, 2007
There's this evil bit of the JDK involving NIO, where deep in the inner loop of a per-byte copy there's a virtual call: ByteBuffer bb = ...;for( int i=0; i<N; i++ ) buf[i] = bb.get(i); No problemo, the JIT will inline the single target, right?Suppose the abstract class ByteBuffer has a single implementing class called DirectByteBuffer (via the abstract class MappedByteBuffer). Then the JVM can prove that any ByteBuffer must be an instance of a DirectByteBuffer (please pardon my not-quite-exact translation to java-pseudo-code):
September 13th, 2007
I like the notion of using arrays to hold collections (efficiency (really cool paper), ease of access), but how do you incrementally migrate a collection from one array to another without blocking? By it's nature, you can't atomically update the entire array at one go. By the nature of concurrency, there can always be a 'late arriving writer' who wants to update the old array and isn't aware that a migration is in progress. If you let the
August 30th, 2007
Came across this surprise while working on a customer app.
August 19th, 2007
One of the more exciting trends in multi-core memory is the idea of Transactional Memory: memory which commits all of it's state-changes atomically or not at all! This idea is very powerful for coding concurrent algorithms, as it means a whole set of updates happen atomically. Azul Systems felt this idea had so much merit that we included some Hardware Transactional Memory (HTM) support (as opposed to
August 6th, 2007
Looks like I need to take some more of my own medicine! Here's code I worked on over a year ago, and it took a year for the data race to finally come home to roost. The following API is fundamentally flawed; no implementation of it can dodge the data race. Here's the deal: I've got a field which from time-to-time is reset to NULL, generally as part of some overall timeout-based cache-flushing policy. It's also in a time-critical function so I'm using lock-free accessing code with lots of comments on proper usage,
June 19th, 2007
I visited FCRC 2007 and all you got was this lousy blog.... The 'F' in 'FCRC' stands for 'Federated' as 'loads and loads' of Computing Research Conferences. 2000 Computer Scientists under one roof! The very idea is... Nerdy. You're allowed to surf between them (the conferences not the scientists), so it's a chance for me to visit some conferences I'd otherwise never visit. The actual trip was very un-inspiring (San Diego is so.... mild), so good for mental focus I suppose.
