It contains a lot of new goodies:

- pessimistic locking (read lock, write lock, exclusive lock)
  - it can be applied automatically on all reads using the read lock level
  - it can be applied automatically on all writes using the write lock level
With pessimistic locking you can put the stm in a pessimistic mode instead of potentially encountering a lot of conflicts. Makes it easier to align with transactional resources. Pessimistic and non pessimistic transactions can be combined without problem. Pessimistic locking
can be done on the ref level but also can be done on the transaction level.

- isolation levels: repeatable read, snapshot, serialized. I have dropped the explicit writeskew setting. It is now controlled through the isolation level or through the ref.ensure.

- out of the box support for alter (bit faster than what currently is used in Akka since the read/writes are faster)

- support for commute.

- atomic operations: atomicget/atomicgetandset/atomicset/atomicalter/atomicincrement etc. They can perform quite a bit faster compared to explicitly using a transaction since there is less overhead.

- transactional collections: transactional hashmap, transactional hashset, transactionalqueue, transactionaldeque, transactionalstack and transactional list.

- propagation levels for transactions   RequiresNew,Requires,Mandatory,Supports,Never. The default for an atomic block is Requires

- support for permanent listeners: this makes registering transaction lifecyclelisteners for each and every transaction something of the past. This should reduce the overhead in Akka quite considerable.
it also makes it possible to add akka logic on transactions that are not explicitly called throught Akka.

- explicit types refs for int, double, boolean, long and object.

- support for an atomicweakget on refs which is extremely fast (only a volatile read is needed). 

It also contains a lot of improvements:

- no autoboxing overhead of the api's are used correctly.

- removal of the central clock (atomic long). So uncontended transactions don't secretly share some resource. This is an issue MVCC STM's like Multiverse 0.6 and Clojure STM suffer from.
This was the biggest thing to get right.

- a lot of performance improvements. The stm should be a few times faster than the 0.6 version.

- 'cheap' transactions are cheap. So if no fancy features are used but only the basic stuff, you get cheap implementations that don't suffer from overhead.

- calling a ref without transaction throws an TransactionRequiredException. So the default propagation level now is Mandatory instead of  Requires.

- the size has been reduces noticeably.  The old one is 800k, the new one will roughly be 250k (no embedded asm anymore). Also 0 external dependencies.

From the outside I don't think there will be much change except from making access
to the additional features possible. So more options when a transaction is created.
All the old structures like ref etc are still there (as well as others). 

The most important change is how the transaction template (which is dropped) should
be used. The new implementation contains an atomic block which essentially does 
the same job as the atomic template and where 5 different types of closures can 
be passed (so returning int, double, boolean, long and ref). This should reduce unwanted
autoboxing to zero.

Another change is that some kind of permanent akka listener needs to be installed
when the stm is created. But since the STM creation is based on a string that 
points to a no arg factory method, you can hook it up to the Akka initialization
mechanism (imho it is better to configure the system in a single uniform way than 
having each component be initialized in a different way). If you point this factory method
to something Akka based and retrieve the settings from Akka, you can directly install the 
permanent listener so that each and every transaction will have one, instead of installing it manually.

So you get something like this:

   public static GammaStm createAkkaStmt() {
        GammaStmConfiguration config = new GammaStmConfiguration();
        config.spinCount = akkaConfig.spinCount
        config.readLockMode = AkkaConfig.readLockMode
        config.writeLockMode = AkkaConfig.writeLockMode
        config.speculativeConfigurationEnabled = AkkaConfig.speculativeConfigEnabled
        config.permanentListeners.add(new AkkaTransactionLifecycleListener());
        return new GammaStm();
    }

    class AkkaTransactionLifecycleListener implements TransactionLifecycleListener{
        void notify(Transaction transaction, TransactionLifecycleEvent e){
           switch(e){
               case Commit: .... do logic here
               case Abort: ... do logic here.
               ....
           }
         }
    }


The parameters to configure the default settings with can be retrieved from the current Akka configuration
mechanism. This example also shows how the permanent listener can be installed that now is available
on all transactions and not just the once started from Akka.

I think this is the parts that needs most fine tuning.

Another part that needs serious tuning is how to maintain a nice Scala feel to the interface when functions
are passed to the refs. I would not like to see a lot of required interface implementations just to pass in 
some function. But that still is something I need to look at (the same goes for Groovy/JRuby since I'm working
on integration on that as well using GPars/Vaclav Pech and Charles Nutter of jruby.

 
This is something we have to get in to 1.1.
How can you have 0 deps and no embedded ASM?

I don't do instrumentation anymore. Will be re-added in a later release, but the current focus is on making 
a STM that can be integrated in JVM based languages.