Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (804)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (867)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Oracle working on an AOT compiler for Java  (Read 64663 times)
0 Members and 1 Guest are viewing this topic.
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 123
Projects: 15


★★★★★


« Posted 2015-08-13 19:15:40 »

Thought this was a pretty interesting announcement by Oracle:

<a href="http://www.youtube.com/v/Xybzyv8qbOc?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/Xybzyv8qbOc?version=3&amp;hl=en_US&amp;start=</a>
Offline theagentd
« Reply #1 - Posted 2015-08-14 00:16:05 »

I don't have an internet connection that can handle videos. -__-' Can anyone give me a TL;DR?

Myomyomyo.
Offline Abuse

JGO Ninja


Medals: 71


falling into the abyss of reality


« Reply #2 - Posted 2015-08-14 00:36:41 »

Tbh I thought that presentation sucked.

This presentation was much better:

https://www.youtube.com/watch?v=uNgAFSUXuwc (completely different topic ofc Smiley
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline philfrei
« Reply #3 - Posted 2015-08-14 04:12:36 »

I needed some background to find out what this discussion was about.
This article has a lot of good information about Java "executable" options, with a section on AOT compilers. It has a comparison of Excelsior and Gnu versions. From 2014. (The author works at Excelsior.)
http://www.excelsior-usa.com/articles/java-to-exe.html

music and music apps: http://adonax.com
Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #4 - Posted 2015-08-14 05:32:58 »

Tbh I thought that presentation sucked.

This presentation was much better:

https://www.youtube.com/watch?v=uNgAFSUXuwc (completely different topic ofc Smiley

I also expected more from the presentation. There were some rumors about that for some time ;-) but the actual implementation he's explaining looks weird to me. Why not just give a way to offline pre-compile it to native code, then it actually can take more time and it would be a one time operation but well... it will be a commercial feature anyways so nobody really cares.

I needed some background to find out what this discussion was about.
This article has a lot of good information about Java "executable" options, with a section on AOT compilers. It has a comparison of Excelsior and Gnu versions. From 2014. (The author works at Excelsior.)
http://www.excelsior-usa.com/articles/java-to-exe.html

This is actually a very different kind of AOT compared to what Oracle is working on.

Offline Roquen

JGO Kernel


Medals: 518



« Reply #5 - Posted 2015-08-14 08:24:10 »

I never watch videos...too much time commitment vs. information.  So what do they mean?  Compiler memorization?  Starting to perform transforms at compile time?  A change in classfile format?  Or the boring thing of AOT to native?
Offline princec

« JGO Spiffy Duke »


Medals: 1136
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2015-08-14 09:19:19 »

The very long and meandering video talks about a quite peculiar form of AOT compilation they're working on which appears to coexist with the JIT stuff.
It does appear to be a peculiar direction to take and is certainly nothing anybody particularly wants... everyone currently content with the JVM as implemented is, well, content. Anyone who needs AOT compilation... needs straightforward, simple, full AOT compilation. There's not much of a middle ground. So this is a bit of a perplexing development really.

Cas Smiley

Offline CommanderKeith
« Reply #7 - Posted 2015-08-14 13:03:23 »

Can anyone give me a TL;DR?
The parts that I watched discussed caching the JIT-compiled hot-spot code to disk. But apparently this presents difficulties due to class-loading order and other traps.
So the speaker experimented with an ahead-of-time static compile which somehow works with the JIT functionality.

Apparently the proposed optimisations could not be fully realised due to budget and time constraints so the speed-ups were less than hoped for. Also, the added code complexity worked against the start-up time savings.

It does appear to be a peculiar direction to take and is certainly nothing anybody particularly wants... everyone currently content with the JVM as implemented is, well, content. Anyone who needs AOT compilation... needs straightforward, simple, full AOT compilation. There's not much of a middle ground. So this is a bit of a perplexing development really.
As an incremental improvement I think it's a good thing. Doing away with the JIT re-compilation of java code seems like a pretty obvious optimisation. Any start-up-time savings are very welcome, in whatever form.

I never watch videos...too much time commitment vs. information.  

I agree. I can't understand why people like the Khan Academy videos to learn maths for that reason. What's more, the video author can't easily edit and improve the video after its recorded. Also, search engines can't index the video.

Offline Roquen

JGO Kernel


Medals: 518



« Reply #8 - Posted 2015-08-14 13:11:59 »

Ok:  so it's compiler memorization.
Offline princec

« JGO Spiffy Duke »


Medals: 1136
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2015-08-14 13:20:40 »

Pretty much. But as I say... it solves a problem people don't really have. Startup time is insignificant next to run duration for any non-trivial application (and by "insignificant" I mean that no-one is really so bothered that I know of who would experience some sort of life-changing epiphany should Eclipse start up in 5s instead of 8s).  For trivial applications the C1 compiler appears to be roughly the same startup time as these experiments. And for those hi-frequency traders who don't want a compile to unexpectedly issue right at the point they perform their first trade - well that's what Excelsior JET is for.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline CommanderKeith
« Reply #10 - Posted 2015-08-14 13:41:15 »

I agree that AOT compilation using Excelsior JET appears to be a better solution.

But startup time is one of the worst aspects of Java programs and creates negative user experiences even for non-trivial programs.
Java GUI freeze when a button is clicked for the first time is very irritating and that's due to JIT compilation.
Native programs seem to be able to start almost instantaneously.

Offline princec

« JGO Spiffy Duke »


Medals: 1136
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2015-08-14 13:52:24 »

I'm sorry, but I've never actually seen this behaviour. The only thing that causes Java UIs to freeze is when people don't know how (or even when) to code multithreaded UIs.
Eclipse starts up here in 8 seconds and it's probably the biggest Java application anyone is ever going to run. An 8 second wait first thing in the morning isn't really going to cause me to tear my hair out in rage and frustration. Likewise reducing that delay to 5 seconds isn't going to save me any of the hair I haven't lost in the first place. It all smacks of a bizarrely contorted form of premature optimisation.

Cas Smiley

Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #12 - Posted 2015-08-14 14:04:31 »

UI freezes are normally not because of JIT recompilation but GC or similar things, or just as princec said: because people write crappy UI code.

Intellij was the first program to prove that Swing UIs are not inherently slow.

Offline princec

« JGO Spiffy Duke »


Medals: 1136
Projects: 3
Exp: 20 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2015-08-14 14:10:18 »

Even GC freezes are largely a myth. In Real Life, GC "freezes" beyond for example a minor intermittent jitter in a game's frame rate just don't happen. Idle UIs just don't produce garbage in any measurable form.

Cas Smiley

Offline Roquen

JGO Kernel


Medals: 518



« Reply #14 - Posted 2015-08-14 14:19:58 »

I think it's a mistake to call "compiler memorization" AOT.
Offline CommanderKeith
« Reply #15 - Posted 2015-08-14 14:26:41 »

I'm sorry, but I've never actually seen this behaviour. The only thing that causes Java UIs to freeze is when people don't know how (or even when) to code multithreaded UIs.
I agree that many GUI programmers don't multi-thread their GUI's enough to hide resource-loading and other freeze scenarios.
I stand corrected that the GUI slowness is probably not due to JIT compilation, but rather the lack of it.
Interpreted non-openGL software-only graphics GUI code is very slow before it has been JIT-compiled.
This is why GUI's often feel unresponsive until they've been 'warmed up'. This is an issue for custom look and feels that tax the software rendering loops, such as the Substance swing look and feel which I liked a lot but would take a while to become fast and responsive.

Since you use Eclipse, which uses the SWT framework's native GUI components, you probably don't see this.

I think that start-up time improvements through caching or static compilation is a great leap forward, in the Neil Armstrong sense, not the Mao Zedong sense  Cool

Offline philfrei
« Reply #16 - Posted 2015-08-14 17:07:12 »

I agree that AOT compilation using Excelsior JET appears to be a better solution.

But startup time is one of the worst aspects of Java programs and creates negative user experiences even for non-trivial programs.
Java GUI freeze when a button is clicked for the first time is very irritating and that's due to JIT compilation.
Native programs seem to be able to start almost instantaneously.

This initial slowness definitely happens with audio coding, and is well known enough to get special mention in a very good article on low-latency audio coding in Java. But there is a work-around: one can code a silent tone to play prior to the first time that audio is heard. Though, that consumes a bit of time, too.

As a developer using Eclipse, I agree that a few extra seconds of startup time is not a problem. But I can also see where the transition from interpreted to compiled could color a common user's experience of Java, and unfairly affect its reputation.

music and music apps: http://adonax.com
Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #17 - Posted 2015-08-14 17:30:14 »

I think it's a mistake to call "compiler memorization" AOT.

What they call AOT is AOT. They compile to native code without any kind of runtime information but the JIT is able to recompile afterwards. That is their current architecture, however it feels wrong - still Cheesy

Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #18 - Posted 2015-08-14 17:33:11 »

This initial slowness definitely happens with audio coding, and is well known enough to get special mention in a very good article on low-latency audio coding in Java. But there is a work-around: one can code a silent tone to play prior to the first time that audio is heard. Though, that consumes a bit of time, too.

As a developer using Eclipse, I agree that a few extra seconds of startup time is not a problem. But I can also see where the transition from interpreted to compiled could color a common user's experience of Java, and unfairly affect its reputation.

If you code a game you anyways have a very clear hot path, just lower the JIT threshold to 100 or so Wink

Offline Roquen

JGO Kernel


Medals: 518



« Reply #19 - Posted 2015-08-14 18:06:26 »

Humm.  So there is no compiler memorization in this talk?  javac is generating native code in addition to bytecodes?  I'm getting the impression I'm glad to not have watched the video Wink
Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #20 - Posted 2015-08-14 18:23:59 »

Humm.  So there is no compiler memorization in this talk?  javac is generating native code in addition to bytecodes?  I'm getting the impression I'm glad to not have watched the video Wink

It is not javac that generates the native code, it is a AOT compiler inside the runtime that just starts to produce native code (current shared objects - .so files) at runtime. It will probably only create them once and reuses them the next time (memorization) but the JIT can override the AOT compiled code whenever it has enough metrics.

Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #21 - Posted 2015-08-14 21:12:42 »

mhm, primitive generics, much more interesting Wink
Offline Roquen

JGO Kernel


Medals: 518



« Reply #22 - Posted 2015-08-14 22:40:03 »

Sounds like someone's smoking crack...or I'm completely misunderstand this.  The sane time to memorize is after interpretation/stats-gathering and all (expected) standard compilations have already occurred and re-use this memorized version at load time iff hotspot and classfile are the same.  The runtime has to be able to override memorized versions...example optimistic choice is disproven (really memorized just allows bypassing)
Offline basil_

« JGO Bitwise Duke »


Medals: 418
Exp: 13 years



« Reply #23 - Posted 2015-08-14 23:54:44 »

i couldn't follow the presenter that good.

i guess you're talking about a cache and not aot, like ahead of. their demo compiles every path statically which generates too many classes to be any beneficial ... or was that the other topic.  persecutioncomplex
Offline ags1

JGO Kernel


Medals: 367
Projects: 7


Make code not war!


« Reply #24 - Posted 2015-08-15 00:22:04 »

Stopped listening at "commercial feature".

Offline noctarius

JGO Knight


Medals: 61


Manager Developer Relations @Hazelcast


« Reply #25 - Posted 2015-08-15 10:35:09 »

mhm, primitive generics, much more interesting Wink

I just finished an article about the new world after sun.misc.Unsafe which includes also a short view on specialized generics. Will hopefully released begin of next week. Smiley

Pages: [1]
  ignore  |  Print  
 
 

 
Riven (397 views)
2019-09-04 15:33:17

hadezbladez (5280 views)
2018-11-16 13:46:03

hadezbladez (2204 views)
2018-11-16 13:41:33

hadezbladez (5544 views)
2018-11-16 13:35:35

hadezbladez (1150 views)
2018-11-16 13:32:03

EgonOlsen (4584 views)
2018-06-10 19:43:48

EgonOlsen (5462 views)
2018-06-10 19:43:44

EgonOlsen (3119 views)
2018-06-10 19:43:20

DesertCoockie (4016 views)
2018-05-13 18:23:11

nelsongames (4708 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!