Hacker News Reader

Hacker News

Comment by valarauca1 | Hacker News Reader

Parent Full thread

valarauca1

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.

View on HN

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

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

An optional link step at build time is coming in Java 9. http://openjdk.java.net/jeps/282

So if you use .class files instead of .jar files, you'll start up significantly quicker?

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.

"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.

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.

wait. since when is 24-48MB trivial?

I would have hoped to see it sub 5MB.

Since we have significantly more RAM to spare than a few years ago and caching, almost by definition, is nothing but trading memory for cpu cycles. You want less memory? No problem, just remove the cache and recompute everything all the time, but don't cry if it takes time.

If 24-48MB is trivial completely depends on what is stored in this space, i.e. is there a more efficient representation for your stated goals? Context is king. Even 5MB could be non-trivial, depending on context.

Since Java.

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.

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

Ahah,what about using an actual JVM for embedded hardware, instead of trolling?

If you don't know better I can gladly provide you some links to embedded Java vendors.

My point was that Java uses a lot of memory and < 5MB for code cache was an unrealistic expectation.

I welcome concrete counterexamples of why this expectation would be realistic.

Aonix PERC Ultra and Pico are into a few KB. Sorry documentation is no longer available since PTC bought Aonix

http://www.ptc.com/developer-tools/perc

JamaicaVM requires 1 MB

https://www.aicas.com/cms/en/JamaicaVM

MicroEJ can target Cortex-M processors with 128 KB flash and 32 KB RAM.

http://www.microej.com/products/device-software-development/...

Oracle's offerings, Java ME Embedded reference implementation requires 128 KB RAM and 1 MB ROM

http://www.oracle.com/technetwork/java/embedded/javame/index...

Java ME might not seem relevant in 2016, but it is running on the majority of Ricoh copiers

https://www.ricoh.com/esa/features.html#01

And smart devices produced by Gemalto like Cinterion, EHS6 digital phone or smart meters.

http://www.gemalto.com/m2m/development/innovation-technology...

http://www.gemalto.com/m2m/solutions/modules-terminals/indus...

Cisco phones,

http://www.cisco.com/c/en/us/products/collateral/collaborati...

And many other embedded manufactures, that are jumping into IoT.

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.

> 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).

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

I'm surprised to hear anyone running Java in the trading industry. Isn't speed a huge factor in that industry?

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

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.

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.

The JVM is super speedy, if you can mitigate startup time and the time required to warm up the JIT.

... and Distruptor/Aeron. (etc.)

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/ [2] http://martinfowler.com/articles/lmax.html

And disruptor is a few years old now, there is a whole new wave of queues with even better performance.

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.

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.

For example:

https://github.com/OpenHFT

Thus the Java.

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.

Java's GC isn't why it can be slower than C/C++ and the JIT (HotSpot) has nothing to do with the GC.

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.

A lot of firms will run some training data through their application after startup, so that the hot paths get optimised.

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.

Or today's trading is different enough from yesterday's that your app hits perf issues. Black swan, anyone?

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.

> you are one bitflip away from sending bad stuff to prod.

Including some ascii art of Trogdor the Burnanator!

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

Except at the exchange, where you can't do this. Or you accidentally bitflip something and take yesterdays data, inject into todays books, and cause millions of dollars in mistakes.

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

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

The "just" part doesn't make a lot of sense but otherwise it's a fair characterization

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?)

Almost all commercial JDKs support AOT to native code.

Sun was religious against it.

Regarding the GCJ, it failed because it is a hard problem where people didn't work for free and most of them stopped working on it when the OpenJDK was released.

Do you know if any commercial JDKs release any metrics on the use of this?

Unfortunately no, I am aware of them, because as language geek I like to research these subjects.

While others read newspapers on the train, I read papers. :)

In any case, these provide AOT.

JamaicaVM, PTC Perc (former Atego and Aonix), IBM J9, Oracle Embedded Java, OS/400 Java (uses the same bytecode deployment as the other OS/400 languages), Excelsior JET, and probably a few others in embedded market that I am not aware of.

And of course the Android Java fork with ART.

Awesome, thanks for responding. I have the same hobby of reading up on this sort of stuff, so I knew of quite a few of those. Just don't know of much for a use case of them.

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.

I had thought Sun did back one of the early methods of compiling to native. (Pretty sure my memory is just wrong.)

Sun only supported it on bare metal embedded scenarios, they were religiously against it.

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

Reply on news.ycombinator.com