SF/JavaOne, Day 4, Speculative Locking


Extremely interesting talk today about making a highly scalable VM for
java that can handle a high number of threads far better than the
current VMs out there.  What’s better than that?  It runs
your code better without requiring you to change any of your code at
all.  How does it work?  At a high level it allows the VM to
actually run your synchronized code in parallel across all running
threads, and you only pay a penalty if there would have been data
contention between two threads.  In the common case there will be
no problem and your thread will execute the critical section *without*
acquiring a lock.  And if there is a conflict it can be detected
with existing techniques, and standard transactional rollback methods
can come to the rescue here.  Apperantly this idea comes into play
in databases and is used to allow scalable performance on machines with
a high number of CPUs (like 128+).  It sounds very interesting,
but i’m extremely confused how it deals with those pesky issues
maintaining atomicity or consistancy.



With their testing they’ve found that the can an amazing level of
scaling where in previous systems you could hit a wall extremely
quickly.



It’s enormously interesting, and far too complicated to go into depth
fully in this post.  So if you want to read more google a
bit.  From that, i found this very interesting paper on the the topic.



Comments (1)

  1. damien morton says:

    interesting – a friend pointed the following paper out to me and i thought of your post on speculative locking.

    http://dal.i.am/cs/fp/ea8-composablememory_stm.pdf

Skip to main content