Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (491)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Why is java not like heaven for AAA game companies?  (Read 4229 times)
0 Members and 1 Guest are viewing this topic.
Offline Several Kilo-Bytes

Senior Member


Medals: 11



« Reply #30 - Posted 2013-09-06 23:25:08 »

Java programs do not run in a VM any more. Java compilers target a virtual machine; meaning a virtual instruction set, not an interpreter. It's called an intermediate representation because source code is transformed to an intermediate format before being translated again to native code. Compilers can be made to target different instruction sets. Some compile directly to native code. Android also uses an intermediate virtual instruction set which is different from the JVM specifications. By your logic C and C++ would also not be suitable for consoles.

The two major open source C compilers, the GCC C compiler and Clang also use a virtual machine specification. GCC compilers use two intermediate languages called "GENERIC" and "GIMPLE". Clang targets an intermediate instruction set for a made up machine called "LLVM" or "Low Level Virtual Machine". The JVM, GIMPLE, and the LLVM all use the same strategy. (Did I also mention IL for the .NET platform?) It enables x source code languages to target y platforms and only x + y translators need to be written instead of x * y unique compilers. Most generic optimizations are done on the intermediate representation in order to further reduce code duplication.

People hear virtual machine and they think interpreter. They should think hypothetical computer. They are as well defined as a real computer architecture (usually better because there are no undocumented quirks) and are designed to be portable and make optimization easy. The JVM is special because it is a computer that supports heap allocation without using pointers, which has a lot of benefits, though there are also some flaws in the platform that are unfortunate in hindsight. The JVM is a fully functional machine specification. Real world physical computers (hardware) that conform to the specification exist and run Java bytecode directly, but the norm is for bytecode to be (re)compiled to native machine code before it is run.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #31 - Posted 2013-09-07 04:22:01 »

Java programs do not run in a VM any more.

Patent nonsense.  The JIT compiles methods that have run several thousand times, and it uses the tracing information it collects during bytecode execution in order to do so.  That's why it methods in the server VM require more calls as bytecode before they're ever compiled.  And it's still designed to back out to bytecode whenever it needs to, such as in the face of new overloads appearing.

JVM Bytecode is starting to resemble something like an IR, but that doesn't mean it is one.
Offline Several Kilo-Bytes

Senior Member


Medals: 11



« Reply #32 - Posted 2013-09-07 17:06:54 »

Java programs do not run in a VM any more.

Patent nonsense.  The JIT compiles methods that have run several thousand times, and it uses the tracing information it collects during bytecode execution in order to do so.  That's why it methods in the server VM require more calls as bytecode before they're ever compiled.  And it's still designed to back out to bytecode whenever it needs to, such as in the face of new overloads appearing.

JVM Bytecode is starting to resemble something like an IR, but that doesn't mean it is one.

Okay, you're right because there is an interpreter in HotSpot. That said, the majority of the time it won't be in use and really doesn't need to be used at all. Its not that much different than having a scripting engine and 1000 is a small number in the computer world. Of course that is how HotSpot treats Java bytecode. Not every platform, device, or compiler does it that way. You wouldn't just port HotSpot and call it good.

For future reference I will try to look to see if the interpreter works on an instruction level or method level. For tracing information you only need to watch which branch is taken, so you do not necessarily need to emulate a CPU to get that information. How IR is used does in one part of one program does not change the fact it is IR. LLVM has an interpreter and bytecode may be used as IR for Android and GCJ.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sproingie

JGO Kernel


Medals: 202



« Reply #33 - Posted 2013-09-07 18:34:23 »

LLVM is designed from the start to support a static compiler target and includes things like load and store opcodes for arbitrary memory addresses.  The high level the JVM operates at gives hotspot a lot of flexibility in the optimizations it makes, but it does complicate the hell out of AOT compilation, usually necessitating a lot of extra runtime support and instruction scheduling that isn't always optimal, something resembling C++ code that's extra-heavy on vtables.

It's not an impossible problem, but C++ compilers haven't exactly sit still in the meantime either.
Offline Several Kilo-Bytes

Senior Member


Medals: 11



« Reply #34 - Posted 2013-09-07 20:58:29 »

I don't disagree that LLVM is a better IR. I said there are flaws in the JVM and the same is true for the Java language.

If you wanted to make JIT compilation or run time profiling part of your final distribution, just do it before it reaches your customer. Supposing your game was deterministic, why could you not what technical constraint prevents you from hypothetically reusing trace information from a PC and sharing it with a different PC, a tablet, or a console? Testing and profiling is part of the development process, why not make it part of the build process? The same statistics could be reused on multiple machines. You could put compiler hints in comments or annotations or in a type of byte code.

You could do what Microsoft did to address long boot times. (The first time you run Windows on new hardware it takes a long time to boot. After it successfully boots it dumps RAM to the hard drive and loads certain parts the same way it would as restoring from hibernate.) You could have console game programmers (or PC programmers since Java for consoles would presumably still be cross platform) do incremental stress tests and dump the results of JIT compilation to a format that a console can read. You could even strip away the dynamic portions of the JRE the same way you do with support structures with clay and plastic 3D printing models while they are still being built and before they harden. (You would have to get rid of reflection and disable the optimistic HotSpot optimizations that require deoptimization if an exceptional case is found, but those aren't used in console games anyway.)

Normally people insist that AOT compilers are a more practical way to do anything a JIT does. You don't hear people argue very often that if given the amount of compilation time that console developers get you could not reproduce with AOT what JIT gives you.

If console developers collectively wanted to use Java they probably could make something happen. There are flaws in every language and Java's are mainly things that can be avoided if you are willing for your performance critical code to look more like C code than clean Java code. Of course it still might not be worth it. Personally I would invest the energy in a new language because there is still lots of room for improvement over all existing languages.
Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #35 - Posted 2013-09-09 08:07:10 »

If you wanted to make JIT compilation or run time profiling part of your final distribution, just do it before it reaches your customer. Supposing your game was deterministic, why could you not what technical constraint prevents you from hypothetically reusing trace information from a PC and sharing it with a different PC, a tablet, or a console? Testing and profiling is part of the development process, why not make it part of the build process? The same statistics could be reused on multiple machines. You could put compiler hints in comments or annotations or in a type of byte code.
There's nothing at all stopping someone from doing it. Small hint ... watch JavaOne closely this year.

Cas Smiley

Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (15 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (29 views)
2014-08-22 19:31:30

atombrot (41 views)
2014-08-19 09:29:53

Tekkerue (38 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (25 views)
2014-08-16 06:20:21

Tekkerue (35 views)
2014-08-16 06:12:11

Rayexar (72 views)
2014-08-11 02:49:23

BurntPizza (48 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59: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!