7 ms·

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 t

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
    Thus the Java.
  - eternalban 10y ago
    > Isn't speed a huge factor in that industry? Exactly. There are a lot of high performance system written in Java. For long running systems, the startup cost is irrelevant. And for networked systems (such as fintech) you are going to be IO bound. The main issue as far as Java and high performance is the GC related pauses and that is a concern shared with any GC'd runtime.
    - PeCaN 10y ago
      And for Java it's actually much less of an issue thanks to the crazy manhours put into developing fast GC for Java. I suspect Azul Systems's pauseless GC is probably quite popular in HFT.
      - brianwawok 10y ago
        They are trying to sell it for sure. They attend a lot of events. I am not aware of any trading company using it. May be some.. but the high perf people I know go other ways.
  - chrisseaton 10y ago
    For example: https://github.com/OpenHFT https://github.com/OpenHFT
  - taneq 10y ago
    I seem to recall a prior discussion where a dev working on HFT stuff said that speed is a huge factor, but so is the ability to rapidly change functionality. They settled on Java because it was fast enough (HFT would have to be IO bound, right?) while still being flexible enough to allow them to adapt to daily changes in requirements.
  - pjmlp 10y ago
    Besides what the others already replied, the use in the trade industry is one of the reasons of Java having to adopt AOT, value types, JNI replacement and better integration with GPGPUs.
  - kitd 10y ago
    You're assuming Java is slow. Evidence suggests otherwise. Eg. LMAX Exchange uses a lock-free ringbuffer they call Disruptor [1] which enables 6M tps on a single thread [2] [1] https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/ [2] http://martinfowler.com/articles/lmax.html http://martinfowler.com/articles/lmax.html
    - brianwawok 10y ago
      And disruptor is a few years old now, there is a whole new wave of queues with even better performance.
  - nurettin 10y ago
    Java shot itself in the foot with the whole GC thing. Then it built a gigantic robot exoskeleton called Hotspot to help itself walk fast again.
    - lucian1900 10y ago
      Java's GC isn't why it can be slower than C/C++ and the JIT (HotSpot) has nothing to do with the GC.
      - nurettin 10y ago
        Well you just told that to someone who lived with GC pauses and profilers for years. And I did not say hotspot is about GC.
- deleted 10y ago
  [deleted]
- WatchDog 10y ago
  A lot of firms will run some training data through their application after startup, so that the hot paths get optimised.
  - kasey_junk 10y ago
    I have done this so can confirm, but every time I did I wished I didn't need to. I had a running nightmare where yesterday's trading data made us trade today.
    - greglindahl 10y ago
      Or today's trading is different enough from yesterday's that your app hits perf issues. Black swan, anyone?
      - brianwawok 10y ago
        Might not even be that. At some point you need to cut out the output from going to the real exchange. If you had an IF somewhere random in your code.. you will then JIT code that is wrongly optimized. If you try to put some kind of network device to capture the traffic and respond with fake responses to make the code happy.. you are one bitflip away from sending bad stuff to prod.
        kasey_junk 10y ago
        > you are one bitflip away from sending bad stuff to prod. Including some ascii art of Trogdor the Burnanator!
        brianwawok 10y ago
        Ya that is tricky with binary formats. What exchanges still support ASCII? I want to send messages that are both ASCII art and a valid trade...
  - brianwawok 10y ago
plandis 10y ago
Those savings might still be beneficial. For instance this might be a decent speed up for GC Functions / AWS Lambda
agentgt 10y ago
"Non-tiered AOT compiled code behaves similarly to statically compiled C++ code, in that no profiling information is collected and no JIT recompilations will happen." My question is how much memory can be saved by not having the JIT. Sure you still have a GC with a heap (VM) but one of the big pigs in memory can be the JIT.
- valarauca1 10y ago
  This is an interesting question. The JVM CodeCache is normally rather small 24MB-48MB. But the JIT and all of its IR/Branch tracking? I Imagine non-trivial.
  - daurnimator 10y ago
    wait. since when is 24-48MB trivial? I would have hoped to see it sub 5MB.
    - paulddraper 10y ago
      Since Java.
      - myrion 10y ago
        Rather since we have multi-gig RAM on consumer machines. On embedded systems it might not be trivial, but on my laptop with its 4gigs of RAM and even more so on my desktop with 16gigs, 50mbs is definitely trivial.
      - pjmlp 10y ago
        Java can run in a few hundred KB, and is actually used a lot by electronic manufacturers. There are quite a few manufacturers that have been replacing their firmware with such versions of Java.
        paulddraper 10y ago
        How may I get this JVM you speak of? $ java -version openjdk version "1.8.0_91" OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) $ java -Xmx999k Error occurred during initialization of VM Too small initial heap
taeric 10y ago
This sounds like it is just a modern gcj, then. Am I reading it wrong?
- oldmanjay 10y ago
  The "just" part doesn't make a lot of sense but otherwise it's a fair characterization
  - taeric 10y ago
    Sorry, if you are reading it as "no big accomplishment", yeah, not right. My question is really "why will it succeed this time?" Did GCJ and similar technologies not take off because Sun didn't support them? Or because it is a really neat technical challenge that solves a problem people don't actually care about? So, yes, this is cool. But, I'm currently giving it a likelihood of success really low, since I have priors that failed. What other evidence are people seeing that make this something to be excited about, as opposed to just impressed. (Or, are we just impressed and I can go back to my corner?)
    - oldmanjay 10y ago
      I think the big distinguishing feature is that this is first-class support built into the platform, so it will likely have many more users than previous efforts. I don't anticipate it being generally useful until at least JDK11, though.
      - taeric 10y ago
        I had thought Sun did back one of the early methods of compiling to native. (Pretty sure my memory is just wrong.)
        pjmlp 10y ago
        Sun only supported it on bare metal embedded scenarios, they were religiously against it.
the8472 10y ago
> No dynamic byte code (Lambda Expressions, Dynamic Classes, etc.) That just means it won't be AOT compiled. The JVM can still JIT them. > No decrease to JVM start up times The JVM itself starts quite fast. Most of the time spent in startup comes from the applications themselves. Spend a lot of time in the interpreter running their startup code and burning CPU cycles on the lower compiler tiers. > The only supported module is java.base Supported in the sense of oracle offering support. You can still compile other modules. It's just experimental.
- bluejekyll 10y ago
  > The JVM itself starts quite fast. Most of the time spent in startup comes from the applications themselves. Jar unpacking can contribute quite a bit to startup times. It would be neat if this also did a pre-linked library as well.
  - lern_too_spel 10y ago
    An optional link step at build time is coming in Java 9. http://openjdk.java.net/jeps/282 http://openjdk.java.net/jeps/282
  - paulddraper 10y ago
    So if you use .class files instead of .jar files, you'll start up significantly quicker?
    - bluejekyll 10y ago
      Yes. In fact many systems unpack jars to a temporary directory first for this reason. edit: I should add that this really only matters for large numbers and sizes of jars.
duaneb 10y ago
Can you statically compile executables? That's a huge win right there.
0xFFC 10y ago
> Only 64bit Linux on AMD64 is supported, so no ARM or Android support currently. Do you know what you are talking about ? Android is totally different thing than JVM and Java Ecosystem ! It is totally different technology ! They use one step to turn your bytecode to their own dex file, after that it is completely separated from Java ecosystem (Java as ecosystem which comes from Oracle). I am fascinated on HN, how comment uneducated like this, haven't got down voted. They use kind of hybrid AOT/JIT right now. (It was interpreter until 2.2, they switched to JIT, in android 5 they switched to complete AOT, now they are going kinda hybrid approach).

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
  Thus the Java.
- eternalban 10y ago
  > Isn't speed a huge factor in that industry? Exactly. There are a lot of high performance system written in Java. For long running systems, the startup cost is irrelevant. And for networked systems (such as fintech) you are going to be IO bound. The main issue as far as Java and high performance is the GC related pauses and that is a concern shared with any GC'd runtime.
  - PeCaN 10y ago
    And for Java it's actually much less of an issue thanks to the crazy manhours put into developing fast GC for Java. I suspect Azul Systems's pauseless GC is probably quite popular in HFT.
    - brianwawok 10y ago
      They are trying to sell it for sure. They attend a lot of events. I am not aware of any trading company using it. May be some.. but the high perf people I know go other ways.
- chrisseaton 10y ago
  For example: https://github.com/OpenHFT https://github.com/OpenHFT
- taneq 10y ago
  I seem to recall a prior discussion where a dev working on HFT stuff said that speed is a huge factor, but so is the ability to rapidly change functionality. They settled on Java because it was fast enough (HFT would have to be IO bound, right?) while still being flexible enough to allow them to adapt to daily changes in requirements.
- pjmlp 10y ago
  Besides what the others already replied, the use in the trade industry is one of the reasons of Java having to adopt AOT, value types, JNI replacement and better integration with GPGPUs.
- kitd 10y ago
  You're assuming Java is slow. Evidence suggests otherwise. Eg. LMAX Exchange uses a lock-free ringbuffer they call Disruptor [1] which enables 6M tps on a single thread [2] [1] https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/ [2] http://martinfowler.com/articles/lmax.html http://martinfowler.com/articles/lmax.html
  - brianwawok 10y ago
    And disruptor is a few years old now, there is a whole new wave of queues with even better performance.
- nurettin 10y ago
  Java shot itself in the foot with the whole GC thing. Then it built a gigantic robot exoskeleton called Hotspot to help itself walk fast again.
  - lucian1900 10y ago
    Java's GC isn't why it can be slower than C/C++ and the JIT (HotSpot) has nothing to do with the GC.
    - nurettin 10y ago
      Well you just told that to someone who lived with GC pauses and profilers for years. And I did not say hotspot is about GC.
deleted 10y ago
[deleted]
WatchDog 10y ago
A lot of firms will run some training data through their application after startup, so that the hot paths get optimised.
- kasey_junk 10y ago
  I have done this so can confirm, but every time I did I wished I didn't need to. I had a running nightmare where yesterday's trading data made us trade today.
  - greglindahl 10y ago
    Or today's trading is different enough from yesterday's that your app hits perf issues. Black swan, anyone?
    - brianwawok 10y ago
      Might not even be that. At some point you need to cut out the output from going to the real exchange. If you had an IF somewhere random in your code.. you will then JIT code that is wrongly optimized. If you try to put some kind of network device to capture the traffic and respond with fake responses to make the code happy.. you are one bitflip away from sending bad stuff to prod.
      - kasey_junk 10y ago
        > you are one bitflip away from sending bad stuff to prod. Including some ascii art of Trogdor the Burnanator!
        brianwawok 10y ago
        Ya that is tricky with binary formats. What exchanges still support ASCII? I want to send messages that are both ASCII art and a valid trade...
- brianwawok 10y ago

plandis 10y ago

Those savings might still be beneficial. For instance this might be a decent speed up for GC Functions / AWS Lambda

agentgt 10y ago

"Non-tiered AOT compiled code behaves similarly to statically compiled C++ code, in that no profiling information is collected and no JIT recompilations will happen." My question is how much memory can be saved by not having the JIT. Sure you still have a GC with a heap (VM) but one of the big pigs in memory can be the JIT.

valarauca1 10y ago
This is an interesting question. The JVM CodeCache is normally rather small 24MB-48MB. But the JIT and all of its IR/Branch tracking? I Imagine non-trivial.
- daurnimator 10y ago
  wait. since when is 24-48MB trivial? I would have hoped to see it sub 5MB.
  - paulddraper 10y ago
    Since Java.
    - myrion 10y ago
      Rather since we have multi-gig RAM on consumer machines. On embedded systems it might not be trivial, but on my laptop with its 4gigs of RAM and even more so on my desktop with 16gigs, 50mbs is definitely trivial.
    - pjmlp 10y ago
      Java can run in a few hundred KB, and is actually used a lot by electronic manufacturers. There are quite a few manufacturers that have been replacing their firmware with such versions of Java.
      - paulddraper 10y ago
        How may I get this JVM you speak of? $ java -version openjdk version "1.8.0_91" OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14) OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) $ java -Xmx999k Error occurred during initialization of VM Too small initial heap

taeric 10y ago

This sounds like it is just a modern gcj, then. Am I reading it wrong?

oldmanjay 10y ago
The "just" part doesn't make a lot of sense but otherwise it's a fair characterization
- taeric 10y ago
  Sorry, if you are reading it as "no big accomplishment", yeah, not right. My question is really "why will it succeed this time?" Did GCJ and similar technologies not take off because Sun didn't support them? Or because it is a really neat technical challenge that solves a problem people don't actually care about? So, yes, this is cool. But, I'm currently giving it a likelihood of success really low, since I have priors that failed. What other evidence are people seeing that make this something to be excited about, as opposed to just impressed. (Or, are we just impressed and I can go back to my corner?)
  - oldmanjay 10y ago
    I think the big distinguishing feature is that this is first-class support built into the platform, so it will likely have many more users than previous efforts. I don't anticipate it being generally useful until at least JDK11, though.
    - taeric 10y ago
      I had thought Sun did back one of the early methods of compiling to native. (Pretty sure my memory is just wrong.)
      - pjmlp 10y ago
        Sun only supported it on bare metal embedded scenarios, they were religiously against it.

the8472 10y ago

> No dynamic byte code (Lambda Expressions, Dynamic Classes, etc.) That just means it won't be AOT compiled. The JVM can still JIT them. > No decrease to JVM start up times The JVM itself starts quite fast. Most of the time spent in startup comes from the applications themselves. Spend a lot of time in the interpreter running their startup code and burning CPU cycles on the lower compiler tiers. > The only supported module is java.base Supported in the sense of oracle offering support. You can still compile other modules. It's just experimental.

bluejekyll 10y ago
> The JVM itself starts quite fast. Most of the time spent in startup comes from the applications themselves. Jar unpacking can contribute quite a bit to startup times. It would be neat if this also did a pre-linked library as well.
- lern_too_spel 10y ago
  An optional link step at build time is coming in Java 9. http://openjdk.java.net/jeps/282 http://openjdk.java.net/jeps/282
- paulddraper 10y ago
  So if you use .class files instead of .jar files, you'll start up significantly quicker?
  - bluejekyll 10y ago
    Yes. In fact many systems unpack jars to a temporary directory first for this reason. edit: I should add that this really only matters for large numbers and sizes of jars.

duaneb 10y ago

Can you statically compile executables? That's a huge win right there.

0xFFC 10y ago

> Only 64bit Linux on AMD64 is supported, so no ARM or Android support currently. Do you know what you are talking about ? Android is totally different thing than JVM and Java Ecosystem ! It is totally different technology ! They use one step to turn your bytecode to their own dex file, after that it is completely separated from Java ecosystem (Java as ecosystem which comes from Oracle). I am fascinated on HN, how comment uneducated like this, haven't got down voted. They use kind of hybrid AOT/JIT right now. (It was interpreter until 2.2, they switched to JIT, in android 5 they switched to complete AOT, now they are going kinda hybrid approach).