14 ms·

JEP 295: Ahead-of-Time Compilation

• deleted 10y ago
  [deleted]
• adamnemecek 10y ago
  The great language convergence is happening! It seems like everyone is moving to expressive statically typed, compiled, functional, oop languages. Not that I'm complaining. This means that we might actually get a language that becomes the new c in terms of popularity.
  • iyn 10y ago
    I look at this as cyclic trends (I'm not sure if 'trend' is the right word here, but it's a good enough approximation) - as you've said, we're entering the cycle of 'expressive statically typed, compiled, functional' (not sure about oop), but soon the cycle will go back to the dynamic languages, because they are "faster when iterating on product" etc. But who knows, maybe we'll stay in current cycle forever? ;)
    • adamnemecek 10y ago
      Yeah it's an extinction event in the evolutionary cycle of computing. Im not sure when was the last one. I think that excessive dynamism is getting less attractive when you account for all the costs it brings with it and that the vast majority of the benefits can be achieved with static metaprogramming, in a more readable and safer manner.
      • pjmlp 10y ago
        When we lost type safety in systems programming to C and C++.
    • galdosdi 10y ago
      I don't think so, well, at least not entirely. :-) Dynamic languages were attractive as an alternative to being forced to specify types all the time, even when it's "obvious." Nobody would have complained if type errors were pointed out for "free." But type inference is getting popular (eg scala), which is showing people that you can have your cake and eat most of it too. There's also a lot of little things like REPLs, runtime metaprogramming, blah blah, that used to be solely the domain of dynamic languages, but popular interpreters/VMs have gotten way better in the last decade or two (thanks, JVM) and shown that you actually _can_ have it all. There's no longer a big strong line between interpreted and compiled. If you can make a statically typed language expressive and fast-to-iterate enough, which I think you can and we (mostly) have, then that kind of yanks the ground right out from under the feet of the dynamic languages, leaving them with no real reason to exist in the long run. That said, there's something attractive to the unexperienced about being able to code in the laziest possible way, and I don't think platforms that deliver a tiny bit of value in the short run in exchange for massive payback in the long run will ever lose popularity, among new engineers who have not yet learned what it's like to maintain a large program. There will always be PHPs as long as there are students. And that's OK. You learn to do thing well by doing things poorly. But hopefully over time such tools will mainly be used for trivial and learning projects, not big mission critical things
      • iyn 10y ago
        I honestly hope you are right :) I've been thinking about type inference in this context but I don't think that's enough to convert people to static languages. I agree that there is a general problem with the 'laziest possible way' to program as you put it - dynamic languages are way more forgiving that static ones. And while tools may evolve to make some things trivial, I think that there (almost) always be some areas where dynamic languages' forgiveness will be good enough reason for some people to use them. Today these are types but in the future there'll be something else to sacrifice.
      • pjmlp 10y ago
        > There's also a lot of little things like REPLs, runtime metaprogramming, blah blah, that used to be solely the domain of dynamic languages If you go read the Xerox PARC, DEC and ETHZ papers you will find REPL goodies using static system programming languages with automatic memory management. The Xerox ones even did correction suggestions when compiler errors happened. Namely Mesa/Cedar, Modula-2+, Modula-3, Oberon and its descendants.
    • greendragon 10y ago
      I don't really see the cycle. I just see it as languages getting closer and closer to Lisp, as per usual. Turns out the static languages had a lot more growing up to do than the dynamic languages, so you're seeing 'big' changes like Java 7 through 9, C++0x through C++1y, new languages like Go, Rust, Nim, Scala... Meanwhile the only recent dynamic languages worth talking about are Clojure, and maybe Julia and Elixir. Across the field of dynamic languages though you see a little more movement to optional typing (and more powerful typing semantics like schema or protocol conformance or other things you can do with dependent types) and maybe some concurrency or JIT or AOT trinkets from other implementations that all boil down to performance improvements of some sort. The language design on the dynamic end has changed much less because they have less to change.
  • rudolf0 10y ago
    So, everything is slowly converging on Scala? (Though of course none will reach the asymptote that is Scala's feature count.)
    • paulddraper 10y ago
      Or, hopefully, the asymptote that is Scala's compile times.
  • duck2 10y ago
    functional, oop Do these have any intersection except Scala?
    • brianwawok 10y ago
      F#
    • Sharlin 10y ago
      Depends on how exactly how functional you want to go, but latest versions of C++, Java, JavaScript, and C# definitely qualify. Rust, too, though it's not strictly OO. And Python, Ruby, Swift.
      • belovedeagle 10y ago
        If Rust is OO then the term is meaningless. No inheritance; dynamic dispatch only via explicit indirection (Boxed traits); methods are (therefore) just syntactic sugar for regular functions.
        • jjnoakes 10y ago
          I disagree; with encapsulation, polymorphism, and composition, Rust seems OO enough to not make the term "meaningless". At least, not according to the widely used definitions I've read of OO.
          • belovedeagle 10y ago
            All of these things are found in Haskell as well; it's not OO by any stretch of the imagination. You're confusing "oop language" with "modern programming language".
            • jjnoakes 10y ago
              https://arxiv.org/abs/cs/0509027 https://arxiv.org/abs/cs/0509027
        • 10y ago
• erl 10y ago
  Important restriction: for the initial release, the only supported module is java.base I.e, we will not be able to compile our own code ahead of time just yet.
  • Alupis 10y ago
    > I.e, we will not be able to compile our own code ahead of time just yet. That's not really true. From the same doc: > AOT compilation of any other JDK module, or of user code, is experimental. So it's "experimental", but possible to do.
• alistproducer2 10y ago
  This is very exciting! Question for the experts out there, do you think this has the potential to do away with using the JNI in new projects for the speed boost?
  • teraflop 10y ago
    This change has nothing to do with JNI whatsoever. The JVM has always (well, not always, but for 15+ years) run Java code by first compiling it to native code. The only difference is that the JVM will now allow you to optionally do the compilation ahead of time, in order to decrease an application's startup overhead. This actually hurts performance of the compiled methods, since runtime profiling is not available to the AOT compiler (but the document also describes a "tiered" mode, where AOT-compiled code can be dynamically replaced with a better JIT-compiled version at runtime). If you want to link your Java code with native code written in a non-Java language, that's a totally different requirement, and JNI will continue to be the way to accomplish it.
    • pjmlp 10y ago
      > JNI will continue to be the way to accomplish it. Not on Java 10 hopefully.
    • wtetzner 10y ago
      > and JNI will continue to be the way to accomplish it. Although if you don't like JNI, you can use JNA [1] (which I believe uses JNI to link to libffi, and libffi for the rest). [1] https://github.com/java-native-access/jna https://github.com/java-native-access/jna
  • the8472 10y ago
    There already are alternatives for JNI. You can use JNR[0] and JNA[1] which allow you to access native libraries by writing java. In some future version panama[2] will offer similar functionality to JNR. [0] https://github.com/jnr/jnr-ffi https://github.com/jnr/jnr-ffi [1] https://github.com/java-native-access/jna https://github.com/java-native-access/jna [2]http://openjdk.java.net/projects/panama/ http://openjdk.java.net/projects/panama/
• samfisher83 10y ago
  C# had this for a while with ngen.
  • buster 10y ago
    C++ had this for even longer. Assembler doesn't even need a compiler..
    • FrancoDiaz 10y ago
      Right, Assembler only needs an assembler
      • valarauca1 10y ago
        Still needs a linker
        • lomnakkus 10y ago
          Pffft... you're using a libc, or something? Direct Syscalls[1] are where it's at. [1] https://en.wikibooks.org/wiki/X86_Assembly/Interfacing_with_Linux https://en.wikibooks.org/wiki/X86_Assembly/Interfacing_with_...
    • samfisher83 10y ago
      C# and Java are very similar. That is the only reason I mentioned it.
• shuntress 10y ago
  Isn't java already compiled ahead-of-time? You give the JVM a .class file, not a .java file. Though this is a technicality. Java 9 will be able to compile java source code to java byte code then compile that java byte code to native machine code, correct?
  • mason55 10y ago
    It is compiled to intermediate byte code but not machine code. You still need the JVM to JIT the byte code to something the CPU can deal with.
    • jsprogrammer 10y ago
      Not necessarily. Java byte code can be run directly on a JPM (Java Physical Machine).
      • jerven 10y ago
        Are there any that support the current class file format? ARM jazelle is no longer being worked on. So I would be surprised if there is anything that can do Java SE directly. JavaCard of course being quite different than standard Java.
        • imtringued 10y ago
          Java bytecode is too highlevel for it to be suitable to run directly on hardware. Each instruction can map to multiple machine instructions. A JIT or AOT compiler can optimize the code on a lower level. A hardware implementation cannot do inlining, loop unrolling, hoist array length checks out of a loop, etc...
  • jdc0589 10y ago
    compile means "native code" here, not jvm bytecode.
  • brianwawok 10y ago
    Look at class file sometime. It is basically bad C code in appearance. It is nowhere close to assembly type code, which is what the final output of the JIT is.
• aaron987 10y ago
  What, if any, effect might this have on Android, given that its all Java?
  • vanrysss 10y ago
    Probably none. Android runs on a different implementation of the JVM called Android Runtime (ART), previously Dalvik.
  • loeg 10y ago
    None — Android doesn't use Hotspot; they've had their own AOT compilation project for their platform (ART) for some time.
  • gleenn 10y ago
    Android and Oracle's Java have been diverged for quite a while. There aren't any Java 8 features available to Android now, so you sadly shouldn't hold your breath for any Java 9 features either, it will probably be a long, long time.
    • ChemicalWarfare 10y ago
      >>There aren't any Java 8 features available to Android now that is incorrect. https://developer.android.com/guide/platform/j8-jack.html https://developer.android.com/guide/platform/j8-jack.html Just plopped this into my activity to make sure: someList.stream().map(String::toUpperCase).forEach(System.out::println); As long as minSdkVersion is 24 or higher you should be good.
      • pjmlp 10y ago
        Except it doesn't work and is full of bugs. https://www.reddit.com/r/androiddev/comments/59gcr9/who_is_using_jack_how_is_it/ https://www.reddit.com/r/androiddev/comments/59gcr9/who_is_u...
  • spbaar 10y ago
    This probably does not affect android. In 5.0, android switched to AOT with a new VM, ART instead of Dalvik, which was a huge win for performance. Jitter in many, many apps went away completely, especially when scrolling. This did cause install times to increase, however. In 7.0 (or 7.1?) there is a mix of JIT with AOT for code that is deemed hot by a profiler, hopefully bringing the benefits of AOT without the lengthy install times.
• deleted 10y ago
  [deleted]
• valarauca1 10y ago
  Seeing as nobody is reading the fine text * Only 64bit Linux on AMD64 is supported, so no ARM or Android support currently. * Files must be ran on computers they were compiled on, or identical hardware * Still needs GC, only G1 and Parallel GC are supported * No dynamic byte code (Lambda Expressions, Dynamic Classes, etc.) * The only supported module is java.base * No decrease to JVM start up times * Still need the JVM * Some decrease to spin up as there will be less JIT passes that require stopping the world. Effectively this just lets you pre-load .class files into the codecache directly rather then running the ~10k initial byte-code passes before they'd receive a JIT pass and that would happen. Lastly .so is just used as a container so I doubt we can expect to dynamically link against AOT compiled Java in C/C++/Rust land.
  • brianwawok 10y ago
    This is clearly still great for a few places. For example in the trading industry, you would have a few seconds of being very slow when starting up for the week - or anytime you crashed and needed to reboot midweek. Also risk of "hot pathing" the wrong paths if the server comes up during say a market closed time...
    • OldSchoolJohnny 10y ago
      I'm surprised to hear anyone running Java in the trading industry. Isn't speed a huge factor in that industry?
      • lygaret 10y ago
        The JVM is super speedy, if you can mitigate startup time and the time required to warm up the JIT.
        • lomnakkus 10y ago
          ... and Distruptor/Aeron. (etc.)
      • maaaats 10y ago
• bit_logic 10y ago
  For the JVM experts here: how realistic is it for OpenJDK developers to add a command line "-useGreenThreads" option? In Golang, you can create thousands and thousands of threads and there's no issue. If I tried that in the JVM, it would quickly crash. But if there was a "-useGreenThreads" option, I could create Java Executor threadpool of size 50000, use existing http client libraries, and get full concurrency.
  • brianwawok 10y ago
    Why do you need a JVM flag for this? There are libraries that do it. http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/
    • bit_logic 10y ago
      Because that's at the library level. It would require rewriting code to use it which loses one of the big advantages of the JVM (a huge existing ecosystem). If it's at the JVM level (with a command line option to change how threading is done such as -useGreenThreads") then it's transparent to all existing code. I can just use anything (such as existing JDBC library), increase threadpool to levels that would be considered "ridiculous" with current JVM threading system, and it would all work fine. No code changes necessary for existing libraries.
      • brianwawok 10y ago
        Except I don't think you can just magically do that. People do this in Python, but they do it in Python because 1) Python is dumb and has the GIL, much easier to hack in 2) They use reflection to change libraries, but it breaks anytime you would hit native C code. With Java trying to JIT everything, you are now having to change threading at the assembly level. I think it is would be a ton of work to do at the base JVM level. If you look at the people behind the library I linked, it is many of the core Java people. They might have more insight on reasons why it won't work.
      • takeda 10y ago
        Green threads are very different from system threads. With green threads you get an illusion of concurrency, and when coding you need to account that multiple green threads work on a single system thread. There's no way you would get a switch like that, because you interact with them differently. I wish greenthreads would not use "thread" in the name because it causes confusion like in your case.
• StevePerkins 10y ago
  This is very exciting, but still a long way from what people probably think it is at first glance. This isn't "compile your application to an EXE", like Go or Rust. This is "compile some or all of your application to a DLL, and then have the Java runtime use that DLL". In other words, you still need a JRE available. The use case for this is simply optimizing hotspots in some very specialized situations.
  • duskwuff 10y ago
    Not even compile to a DLL, really. The file format happens to be an ELF shared object, but its contents are unusable to anything other than Java, so it's effectively just a blob.
  • pjmlp 10y ago
    Anyone willing to pay for them, can buy a commercial AOT compiler for Java today, there are quite a few available. This is significant for those that want to AOT Java without paying for it.
    • dleskov 10y ago
      Some info for those that want to AOT Java without paying for it: The entry-level edition of Excelsior JET is free (as in beer) since the end of August 2016. Licenses for the more senior editions have been available for non-commercial use at no cost for many years. https://www.excelsiorjet.com/free https://www.excelsiorjet.com/free
  • WatchDog 10y ago
    Hotspots aren't really going to be any faster with this change. The jvm already does a pretty good job of optimising hot code, which is why the vm is literally called hotspot. AOT compilation is mostly intended to address startup time, Java has a big std library and much of it needs to be interpreted and compiled each time it runs. Between jigsaw modules and this, we should see some nice improvements in startup time.
    • jjnoakes 10y ago
• deleted 10y ago
  [deleted]