Tag Archives: oracle

AMD and Oracle to collaborate on Heterogenous Computing in Java

In August John Coomes from Oracle made a proposal to add GPU support to Java. One month later, on Sep 10, he proposed the creation of a new project called Sumatra to continue with this endeavour. On Sep 24 this project was approved by a 100% vote in favour. During the recent JavaOne 2012 AMD officially announced its participation in OpenJDK Project Sumatra in collaboration with Oracle and OpenJDK to bring heterogenous computing to Java for server and cloud environments. The Inquirer also reports on this subject.

This is very exciting news indeed. Although there are already two libraries for GPU programming in Java – namely rootbeer and aparapi, having GPU support built in to the Java language, the Java API and most importantly the JVM will provide an alternative more compelling than the use of any external library. And to be quite frank there could not be a collaborator than AMD given their vast contribution to date to OpenCL and OpenCL development tools. And unlike Nvidia, they are wholly committed to OpenCL and not working on their own proprietary alternative.

Although it’ll be a while before this project sees any substantial contribution I cannot wait to see this take form over the next year or two. OpenCL and, in general, the GPU programming paradigm is hard; very hard; and even more importantly porting existing code is even harder; and if anyone can make this domain accessible to the mainstream it’s Java. Once Sumatra is ready hopefully we won’t have to write OpenCL anymore. We’ll be able to write normal Java, compile it and at either compile time or runtime the byte code will get translated into OpenCL and compiled. At execution time we won’t have to worry about what hardware we’re running because with any luck it’ll be write once run anywhere!

HotSpot PermGen removal commit made

As you may know, after the takeover of Java by Oracle and the subsequent decision to merge JRockit into Hotspot, PermGen was due to be removed from Hotspot entirely. Two days ago, a commit (openjdk list message) has been made into the hotspot gc repository to remove permgen (which is the storage of class metadata) and use native memory in its place. Class metadata shall now be represented as C++ classes and will now be allocated in the metaspace linked to classloaders according to the commit message. [Source]

Java 6 EOL extended to Feb 2013

Oracle has extended the Java 6 end-of-life to Feb 2013. That’s not far away. After that there won’t be any further updates to Java 6. So I suggest we all start moving over to Java 7. Java 7 is now on update 6 and therefore I would say that it’s had enough time to mature as a major release now. A lack of updates for Java 6 is a fairly compelling release to move over as it is inevitable that Java 6 users will encounter JDK bugs in production and if they do then they will no longer have the luxury of receiving fixes through minor updates. And I’m sure I don’t to remind you of all the other reasons to move over. 🙂

Oracle and AMD propose GPU support in Java

A very exciting development indeed has come to my attention albeit four days late. This news is, without exaggeration, in my humble opinion nothing short of groundbreaking, not only because it pushes the boundaries and capabilities of Java even further in terms of hardware support and performance but also because, as I’m gradually beginning to realise, the future of high performance computing is in the GPU.

John Coomes (OpenJDK HotSpot Group Lead) and Gary Frost (AMD) have proposed a new OpenJDK project to implement GPU support in Java with a native JVM (full thread).

This project intends to enable Java applications to seamlessly take advantage of a GPU–whether it is a discrete device or integrated with a CPU–with the objective to improve the application performance.

Their focus will be on code generation, garbage collection and runtimes.

We propose to use the Hotspot JVM, and will concentrate on code generation, garbage collection, and
runtimes. Performance will be improved, while preserving compile time, memory consumption and code generation quality.

The project will also use the new Java 8 lambda language and may eventually sprout further platform enhancements.

We will start exploring leveraging the new Java 8 Lambda language and library features. As this project progress, we may identify challenges with the Java API and constructs which may lead to new language, JVM and library extensions that will need standardization under the JCP process.

John Coomes (Oracle) will lead the project and Gary Frost (AMD) has gladly offered resources from AMD. As the mail thread got underway two already existing related projects were brought to the list’s attention: rootbeer (PDF, slashdot) and Aparapi (AMD page). Rootbeer is a particularly interesting project as it performs static analysis of Java code and generates CUDA code automatically – quite different from compile time OpenCL bindings from Java. The developer of rootbeer has also shown interest in joining the openjdk project. John Rose, Oracle HotSpot developer, also posted a talk he recently gave on Arrays 2.0 which I’m yet to watch.

The missing link in deriving value from GPUs, from what I understand in a domain that I’m still fairly new to, is that GPU hardware and programming need to be made accessible to the mainstream and that’s the purpose I hope this project will serve. I hope also that, once underway, it also raises wider awareness of how we must make a mental shift from concurrency to parallelism and from data parallelism to task parallelism and how the next generational leap in parallelism will come, not from cpu cores or concurrency frameworks, but from harnessing the mighty GPU.

Hacker news has some discussion. What do you think? Let me know.

Three Java releases in one day!

Oracle have just made three java releases (or maybe I’ve only just noticed them).

The 7u1 release fixes six bugs of which two appear to be loop related (1,2). The bug with loop predication was the one that originally tainted the release of Java 7 as you might remember. If I was working for a startup or running my own company I’d move to 7u1 straight away but in a bank that’ll never happen. Still, at least, I’ve managed to persuade them to move to 1.6.0_25 due to a critical CMS fragmentation bug afflicting 1.6.0_23. 🙁

The 6u29 release appears to have skipped a build number which is justified in the release notes. This one has two bug fixes worthy of mention out of a total of five – one is where ‘java.net.InterfaceAddress’s equals method may throw NPE’ (odd) and the other is where there is a ‘Memory leak of java.lang.ref.WeakReference objects’ (how ironic!).

Regarding the mac release it is great to see the Mac get official recognition on the oracle java homepage and have the release packaged as a dmg rather than needing to be built from source. (It’s quite possible by the way that I’ve only just noticed this one and that it’s been there all along or maybe I’d seen this earlier and have forgotten!). Though I’m liking the steady progress Oracle. Keep up the good work. I hope you are working on Java 8 as planned for end of next year!

Java 7 loop predication bugs surface and workaround known

Software and bugs always have been and always will be inseparable. Java 7 certainly wasn’t going to be the first exception to this rule. Unsurprisingly, since internal testing can never compete with the testing that takes place through mass adoption, in less than a day after Java 7’s release bugs surfaced with loop predication.

Oracle are aware of the issues and Mark Reinhold has suggested a work around while they work on fixes for an early update release. Though apparently update 1 will be security fixes only and loop fixes are more likely to appear in update 2 though they will try to push into update 1 if possible. Keep at it Oracle – you have our support.

Supposedly the bugs were found by Apache Lucene and Solr but I’m sure I’m not the first to wonder why these projects neglected to test with all the openjdk nightly snapshots and particularly with the release candidate.

Update [01/08/2011]: The following links provide a bit more insight on what happened: ‘The real story behind the Java 7 GA bugs affecting Apache Lucene / Solr‘ and ‘Don’t Use Java 7? Are you kidding me?

Java 7 released!

As if you didn’t know – Java 7 is released (1, 2, 3). As the linked post says it’s been a long five years but hopefully more regular release cycles and expert innovation of the kind we’ve already seen in Java 7 will become the norm and turn the droves of skeptics, cynics and deserters back to believing in Java and the JVM as the supreme platform.

The delay hasn’t been all bad. In fact I think it’s been quite positive in many ways. The lack of growth of Java has fostered innovation in jvm languages to try and plug the inadequacies while also creating new things. It’s also spurred its loyal users to do more with less and explore alternative languages and paradigms but also contribute back to Java with what they’ve learnt. And in Java 8 with Project Lambda Java now has the benefit of hindsight in being able to examine, for example, how Scala and Clojure have done things, and take the best of all worlds but at the same it will need to compete effectively with other languages both on and outside of the JVM. The ubiquitous nature of Java means that it must grow and compete in all directions to continue to be so.

This is, in my opinion, as I’m sure you realise – if you look back to what’s gone on in the past year and what is to provisionally come in the next year or two – only the beginning. With Oracle heading Java now this is very much a commercial endeavour and with the first release over the audience is more than ever unrelenting and eagerly awaiting the next.

Oracle celebrates upcoming Java 7 release on video

Oracle recently celebrated the upcoming release of Java 7 with great pomp and show and subsequently made recordings of the event available as a series of videos available. If you haven’t already done so watch the videos in order below and read the blog post. There are also some thoughts on what’s upcoming in Java 8 in the final Q&A video.

It’s great to see Oracle engaging with the community to this extent and so publicly. This could have been just another release but I’m glad it received more publicity and visibility in this way, particularly, giving sub-project leads within Java 7 the recognition they deserve and the inspiration to carry on doing their great work I hope. I’ve also subscribed to the Oracle Java Magazine to see what it offers in due time.

Introducing Java 7: Moving Java Forward

Technical breakout sessions

In addition to the main presentation there were also smaller and more specialised technical breakout sessions as below.

Making Heads and Tails of Project Coin, Small Language Changes in JDK 7 (slides)

Divide and Conquer Parallelism with the Fork/Join Framework (slides)

The New File System API in JDK 7 (slides)

A Renaissance VM: One Platform, Many Languages (slides)

Meet the Experts: Q&A and Panel Discussion

Thoughts

A few thoughts that occurred to me having watched the above presentations follow below.

  • In Joe’s presentation I realised just how important good editor support is to prompt developers to adopt the project coin proposals over older ways of achieving the same ends. I was very impressed watching Netbeans detecting older syntax, prompting the developer through providing helpful warnings and being able to change old to new syntax instantaneously. I really hope Eclipse does the same. Eclipse has asked for quick fix, refactoring and template suggestions and in response to that I would say the most important incorporations above supporting the language would be supporting idiomatic transitions from Java 6 and Java 7.
  • Watching Joe Darcy go through how they implemented switch on strings and the associated performance considerations was fascinating. They actually use the hashcode values of strings to generate offsets and then use the offsets to execute the logic in the original case statements.
  • I found it very cool that Stuart Marks actually retrofitted the existing JDK code to utilise some of the Project Coin features not by hand but in an automated fashion. Apparently the JDK team also used annotation based processing and netbeans based tooling to help them upgrade the JDK codebase to use the new features.

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?‘.

JDK7 Project Coin Primer

Although I knew about the small language enhancements going into JDK7, named Project Coin, quite some time back it was only today that I got around to actually coding and trying them all out primarily due to prior laziness and poor editor support. Yes I know – there’s plenty of docs on Project Coin out there already. This is mine.

And now that JDK7 actually has a finite number of steps in its release schedule and is scheduled for release on 28/07/2011 we know our efforts in learning the new feature set are not going to waste and that very soon we’ll be able to write production code with this knowledge to make the industry a better place which is ultimately what is important.

Here I present a quick primer for the uninitiated. The small language enhancements going into JDK7 are as follows.

  1. Strings in switch
  2. Binary integral literals
  3. Underscores in numeric literals
  4. Multi-catch and more precise rethrow
  5. Improved type inference for generic instance creation(diamond)
  6. try-with-resources statement
  7. Simplified varargs method invocation

Below I provide one example per feature that will take you through each feature in a flash.

Strings in switch

A long overdue and seemingly basic feature but better late than never.

package name.dhruba.kb.jdk7;

public class StringsInSwitch {

    public static void main(String[] args) {
        for (String a : new String[]{"foo", "bar", "baz"}) {
            switch (a) {
                case "foo":
                    System.out.println("received foo!");
                    break;
                case "bar":
                    System.out.println("received bar!");
                    break;
                case "baz":
                    System.out.println("received baz!");
                    break;
            }
        }
    }
    
}

Binary integral literals

I can’t say I’ve ever felt the absence of this rather unusual feature. Though it seems it was felt compelling enough to be added in. This is primarily a readability advantage – a semantic representation.

package name.dhruba.kb.jdk7;

public class BinaryLiterals {

    public static void main(String[] args) {

        // An 8-bit 'byte' literal.
        byte aByte = (byte) 0b00100001;

        // A 16-bit 'short' literal.
        short aShort = (short) 0b1010000101000101;

        // Some 32-bit 'int' literals.
        int anInt1 = 0b10100001010001011010000101000101;
        int anInt2 = 0b101;
        int anInt3 = 0B101; // The B can be upper or lower case.

        // A 64-bit 'long' literal. Note the "L" suffix.
        long aLong = 0b1010000101000101101000010100010110100001010001011010000101000101L;

    }
    
}

Underscores in numeric literals

I’ve often found myself adding javadoc to make a constant declaration clearer. This makes them somewhat clearer which is definitely helpful.

package name.dhruba.kb.jdk7;

public class UnderScoredLiterals {

    public static void main(String[] args) {

        long creditCardNumber = 1234_5678_9012_3456L;
        long socialSecurityNumber = 999_99_9999L;
        float pi = 3.14_15F;
        long hexBytes = 0xFF_EC_DE_5E;
        long hexWords = 0xCAFE_BABE;
        long maxLong = 0x7fff_ffff_ffff_ffffL;
        byte nybbles = 0b0010_0101;
        long bytes = 0b11010010_01101001_10010100_10010010;

    }
    
}

Multi-catch

The multi-catch is very useful indeed and significantly reduces the number of lines of code to do such things from before.

package name.dhruba.kb.jdk7;

public class MultiCatchException {

    static class Exception1 extends Exception {}
    static class Exception2 extends Exception {}

    public static void main(String[] args) {
        try {
            boolean test = true;
            if (test) {
                throw new Exception1();
            } else {
                throw new Exception2();
            }
        } catch (Exception1 | Exception2 e) {
        }
    }
    
}

More precise exception rethrow

The more precise rethrow is a tricky one to understand. See if you can spot what the new feature is in the example below. Will it compile on pre-java-7? If not how would it need to be changed to compile on pre-java-7? The answers lie after the example.

package name.dhruba.kb.jdk7;

public class MorePreciseExceptionRethrow {

    static class Exception1 extends Exception {}
    static class Exception2 extends Exception {}
    
    public static void main(String[] args) throws Exception1, Exception2 {
        try {
            boolean test = true;
            if (test) {
                throw new Exception1();
            } else {
                throw new Exception2();
            }
        } catch (Exception e) {
            throw e;
        }
    }
    
}

On Java 6 compiling the above gives the following exception.

Foo.java:18: unreported exception java.lang.Exception; must be caught or declared to be thrown
            throw e;
            ^
1 error

This can be fixed for Java 6 by changing:

public static void main(String[] args) throws Exception1, Exception2 {

to:

public static void main(String[] args) throws Exception {{

So now you see the improvement that Java 7 offers with this feature. You can be more precise in the declaration of the exceptions that you rethrow. Very nice indeed.

Improved type inference for generic instance creation(diamond)

Oh my God. Thank you Oracle for this feature. I breathe a huge sigh of relief. How long has it taken to get this out? How many keystrokes and keyboards have I wasted over the period of my career? And how much of a penalty have the tips of my fingers paid over the years for typing out the right hand side of a generic assigment? This curse is no more. Particularly note the constructor inference which is new to Java 7 also.

package name.dhruba.kb.jdk7;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class GenericDiamondTypeInference {
 
    static class MyClass <X> {
        <Y> MyClass(Y y) {
        }
    }
    
    public static void main(String[] args) {
        
        // constructor inference
        // <X> = <Integer>, <Y> = <String>
        MyClass<Integer> myClass1 = new MyClass<>("");
        
        // standard stuff
        List<String> list = new ArrayList<>();
        Map<String, List<String>> map = new HashMap<>();
        
    }
    
}

try-with-resources statement

This is simply beautiful and incredibly reassuring for the simple reason that resource closing is not only automatic and requires a lot less code but if in the examples below multiples exceptions are thrown (i.e. one in the closing of the resource and one in the use of the resource) then not only does the latter not get swallowed (unlike pre-java-7) but finally you can access all suppressed exceptions (i.e. the former) via the new API.

package name.dhruba.kb.jdk7;

public class TryWithResources {

    static class MyResource1 implements AutoCloseable {
        @Override
        public void close() throws Exception {
            System.out.println("MyResource1 was closed!");
        }
    }
    
    static class MyResource2 implements AutoCloseable {
        @Override
        public void close() throws Exception {
            System.out.println("MyResource2 was closed!");
        }
    }


    public static void main(String[] args) throws Exception {
        /*
         * close() methods called in opposite order of creation
         */
        try (MyResource1 myResource1 = new MyResource1();
             MyResource2 myResource2 = new MyResource2()) {}
    }
    
}

NOTE: In the above example the resources are closed in an order opposite to their order of creation.

Simplified varargs method invocation

This was a very tricky one to investigate. It’s still not clear what ‘simplified varargs method invocation’ is referring to but one difference (improvement) I was able to narrow down was that of a more specific and helpful warning that jdk7 adds to certain varargs code as below.

package name.dhruba.kb.jdk7;

import java.util.Collections;
import java.util.List;
import java.util.Map;

public class BetterVarargsWarnings {

    static <T> List<T> foo(T... elements) {
        return null;
    }

    static List<Map<String, String>> bar() {
        Map<String, String> m = Collections.singletonMap("a", "b");
        return foo(m, m, m);
    }

}

In Java 6 the above generates the following warning.

/Users/dhruba/NetBeansProjects/SwitchTest/src/name/dhruba/kb/jdk7/BetterVarargsWarnings.java:15: warning: [unchecked] unchecked generic array creation of type java.util.Map<java.lang.String,java.lang.String>[] for varargs parameter
        return foo(m, m, m);
                  ^
1 warning

In Java 7 however an additional warning is generated.

/Users/dhruba/NetBeansProjects/SwitchTest/src/name/dhruba/kb/jdk7/BetterVarargsWarnings.java:9: warning: [unchecked] Possible heap pollution from parameterized vararg type T
    static <T> List<T> foo(T... elements) {
                                ^
  where T is a type-variable:
    T extends Object declared in method <T>foo(T...)
/Users/dhruba/NetBeansProjects/SwitchTest/src/name/dhruba/kb/jdk7/BetterVarargsWarnings.java:15: warning: [unchecked] unchecked generic array creation for varargs parameter of type Map<String,String>[]
        return foo(m, m, m);
                  ^
2 warnings

Compiling Java 7

  • Download JDK7. I used OpenJDK OS X Build on my Mac.
  • Download Netbeans 7 which is what I used again on the Mac. Or Intellij 10.5.
  • Be happy. There’s no link for that but if you don’t feel this at this point you may want to think of a change of career.

Thanks to LingPipe for linking to this post.