Tag Archives: jdk8

Brian Goetz talks on implementing lambda expressions in Java 8

Oracle have posted the talk that Brian Goetz (one of my favourite technical experts) gave at the JVM Language Summit on 30 July 2012 on implementing lambda expressions in Java. It’s shorter than a classic talk at only 40 mins long. Lambda expressions are due to be released in Java 8 and will be the flagship feature of that release and will also be, without a shadow of a doubt, one of the most important features of all time.

Not only will they make the language more powerful in its expression but with any luck the VM will also be able to introspect and detect latent areas of parallelism and parallelise the execution of those lambda operations. Numerous satellite projects will also leverage the use of lambda expressions in their endeavours – an example being the recent proposal to add GPU support into Java.

JDK8: StampedLock: A possible SequenceLock replacement

Quite some time back I wrote about SequenceLock – a new kind of lock, due for release, in JDK8 where each lock acquisition or release advanced a sequence number. Two days ago, however, Doug Lea has reported that, for a variety of reasons, this API may be “less useful than anticipated”. Instead he has proposed a replacement API called StampedLock and requested feedback on it.

Here I reproduce example usage of both APIs for for easy comparison by the reader.

SequenceLock sample usage

 class Point {
   private volatile double x, y;
   private final SequenceLock sl = new SequenceLock();

   // A read-only method
   double distanceFromOriginV1() {
     double currentX, currentY;
     long seq;
     do {
       seq = sl.awaitAvailability();
       currentX = x;
       currentY = y;
     } while (sl.getSequence() != seq); // retry if sequence changed
     return Math.sqrt(currentX * currentX + currentY * currentY);
   }

   // an exclusively locked method
   void move(double deltaX, double deltaY) {
     sl.lock();
     try {
       x += deltaX;
       y += deltaY;
     } finally {
       sl.unlock();
     }
   }

   // Uses bounded retries before locking
   double distanceFromOriginV2() {
     double currentX, currentY;
     long seq;
     int retries = RETRIES_BEFORE_LOCKING; // for example 8
     try {
       do {
         if (--retries < 0)
           sl.lock();
         seq = sl.awaitAvailability();
         currentX = x;
         currentY = y;
       } while (sl.getSequence() != seq);
     } finally {
       if (retries < 0)
         sl.unlock();
     }
     return Math.sqrt(currentX * currentX + currentY * currentY);
   }
 }

StampedLock sample usage

class Point {
    private int x, y;
    private final StampedLock lock = new StampedLock();

     public int magnitude() { // a read-only method
         long stamp = lock.beginObserving();
         try {
             int currentX = x;
             int currentY = y;
         } finally {
             if (!lock.validate(stamp)) {
                 stamp = lock.lockForReading();
                 try {
                     currentX = x;
                     currentY = y;
                 } finally {
                     lock.unlock(stamp);
                 }
             }
             return currentX * currentX + currentY * currentY;
         }
     }

     public void move(int deltaX, int deltaY) { // a write-locked method
        long stamp = lock.lockForWriting();
        try {
            x += deltaX;
            y += deltaY;
        } finally {
            lock.unlock(stamp);
        }
    }
}

There are two primary differences that I can see. First of all – in SequenceLock the read only method has an element of indefinite retry without lock acquisition. In StampedLock, however, the retry element is replaced with lock acquisition which would perform better under a lot of writes. Secondly, the single undifferentiated lock in SequenceLock is replaced with a differentiated read and write lock. The latter feature makes this class another alternative to the existing class: ReentrantReadWriteLock that Doug Lea describes as “cheaper but more restricted”. It will be fascinating to watch the progression of this API over time.

JDK8 ConcurrentHashMap gets huge map support

Doug Lea announces huge map support in the latest incarnation of ConcurrentHashMap to more effectively support more than a billion elements.

Finally acting on an old idea, I committed an update to ConcurrentHashMap (currently only the one in our jdk8 preview package, as jsr166e.ConcurrentHashMap8) that much more gracefully handles maps that are huge or have many keys with colliding hash codes. Internally, it uses tree-map-like structures to maintain bins containing more nodes than would be expected under ideal random key distributions over ideal numbers of bins.

It’s nice to see the huge map consideration get some real effort put into it. Mark Reinhold, I believe, talked about huge map 64-bit support as a possible feature in JDK8 onwards in one of the videos hosted by Adam Messinger. I don’t think Doug Lea’s efforts are related to that but rather his own ideas.

JDK8 update: Release schedule and StringBuilder patch

Looking through the jdk8-dev archives (albeit slightly late) I found two points worthy of note. First is the JDK8 release schedule (thread view) as well as commendable openness by the release manager of the release schedule and commitment by Oracle. The second is a movement (thread view) in openjdk to migrate from StringBuffer to StringBuilder which in my opinion is fantastic not only as a means of keeping the codebase up to date in a backward compatible manner but also as a performance improvement. Note the lmax disruptor whitepaper in which benchmarks showed how sychronized code can be slower than unsynchronized code even when only executed by a single thread. On a note of curious trivia: Adam Messinger, who hosted the jdk launch event on video has left Oracle for Twitter to become VP of Application Engineering!

Java SE 8 Developer Preview with Lambda Support

Java SE 8 developer preview released with lambda support. The big question now is which editors support Java 8 and lambda syntax? I wasn’t able to find explicit mention of any editors supporting it -I suspect I’ll have to hack around in vim for a while. If you know please comment.

Oracle discusses Java 7 & 8 new features on video

NOTE: If this post interests you you should definitely check out the Java 7 celebration launch and the detailed technical breakout session videos here.

Watch the fascinating video discussion (also embedded below) about upcoming features in Java 7 & 8 between Adam Messinger, Mark Reinhold, John Rose and Joe Darcy. They talk about quite a few things that may not be general knowledge and certainly haven’t been committed to officially yet.

  • The upcoming Project Lambda in Java 8 will provide multicore support with parallel execution of lambda code. This makes sense as functions just define units of work and whereas the developers define how those units of work are composed they do not need to be concerned about how they are scheduled or sequenced – that’s the VM’s job. An analogy can be drawn between this and the kinds of things that ParallelArray can do.
  • Java 8 will provide Project Jigsaw – Java’s first modularity feature.
  • Java 8 will provide Collection Literals which will finally eliminate boiler plate collection declaration and access code.
  • Java 8 will merge Jrockit into the Hotspot vm. This work has already begun in Java 7 with JMX enhancements and reduction of the use of permgen space. Permgen will be eliminated altogether in Java 7 updates taking inspiration from JRockit.
  • Java 8 may have big data support in collections (large collections) – 64 bit support and primitive collections.
  • There was a considerable amount of talk about the new invokedynamic instruction, the first new instruction since Java5, that will optimise how JVM languages perform but also help with parallelising closures but as I am not a language designer that wasn’t particularly relevant to me though I’m always happy to gain from evolving VM technology as that really is the true essence of Java in my opinion.

Needless to say I cannot wait for Java 7 but I absolutely cannot wait for Java 8. As Mark and Joe said Java 7 is an evolutionary release but Java 8 shall be a revolutionary release. I really must give credit to Oracle for getting all this moving after it remaining stagnant for so many years at Sun. My favourite features in Java7 are Project Coin and NIO2 and in Java 8 will be Project Lambda and Collection Literals though any VM features HotSpot gains from JRockit will obviously be significant.

Also, apparently, Java 7 is out tomorrow (7th July) though that post doesn’t actually clarify whether it’s just the party tomorrow or the release as well. I cannot believe Eclipse still isn’t supporting Java 7 when every other major editor has had this for quite some time. I guess I’ll have to fall back to Netbeans for a while (IntelliJ I just can’t figure out how to use).

Update [17/08/2012]: Nice to see this post featured on the StackOverflow discussion titled ‘Does .NET have something like Java’s permgen?‘.