Thread: Why JIT compilation and not full compilation?

  1. #1
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853

    Why JIT compilation and not full compilation?

    I was viewing a presentation about Android's VM JIT compilation process (quite good). I am far from an expert on the subject but the whole scheme struck me as a bit odd, so it is obvious that I am missing something (probably a few things).
    My question is why not compile fully in native code the whole application once it is on the targeted platform? The answer I find is that it would take too much time to load, which makes sense. But what I am missing here is why would you need to compile every time you load the application and not just once for its lifetime?

    That made me think also if it would be possible just to have "platform compilation", so you send bytecode to the user and it compiles to native code as part of the installation on the targeted device, provide that you really want to gain performance but yet for what the application to remain device independent. During the particular presentation it showed that most of the code is already practically native and that the JIT compilation time is relatively small. Applications processes are also rarely kill in the Android platform so overall the argument of slow loading time (made during same presentation) is not really self explanatory. I mean if the application needs to load files, network resources etc etc then maybe it is even better to give some time to the loading procedure to be compiled natively to do all this a bit faster.

  2. #2
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,229
    Theoretically, JIT can have better performance than native because the compiler can use run time statistics to make optimization decisions.

    We can do profile-guided optimizations with native code, but it would only be optimized for the characteristics of the sample run.

    ... of course, this is purely theoretical. In practice I don't believe that will ever happen (JIT faster than PGO).

  3. #3
    the hat of redundancy hat nvoigt's Avatar
    Join Date
    Aug 2001
    Location
    Hannover, Germany
    Posts
    3,130
    It depends on the JITter. Some cache their results so it's only compiled the first time it's run. Some don't.
    hth
    -nv

    She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."

    When in doubt, read the FAQ.
    Then ask a smart question.

  4. #4
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    For an application with say 100 features (many have much more), how many of those features are likely to be used in any given session, and how many are ever used?
    20% might be used on a regular basis, and 50% at all. Half of it could go unused by any single user (each user has their own 50%).

    Not to mention, the additional user interaction steps to get from one feature to another.

    Take for example your text message application.
    - the new message notification (with read or dismiss options)
    - reading the message
    - composing a reply
    - looking up an address in the address book.
    Each step is a key press, and another window of opportunity to do a bit more JIT'ing.

    You can compile and run quite a bit of code in the 200mS it takes the user to get their finger out of the way to see what is there next

    If you had a single monolithic application that had to be loaded into memory each time, you would likely waste a lot of resources doing it. Whilst Android (for example) uses virtual memory, it does not have a swap device. So loading only "the code you need, when you need it" is seen as a good thing™.

    Java makes this easier, with everything is a class.
    To do the same thing in C++, you would have to make each class a separate DLL - this could get ugly in a hurry.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  5. #5
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Other than on-demand compilation, an advantage I see of JIT languages is that it is much easier for them to implement code reflection features and idioms. This isn't an immediate advantage to memory or otherwise constrained devices, but JIT isn't strictly of their domain either.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  6. #6
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Another advantage is that stack-based bytecode (like Java's bytecode) is considerably more compact than register-based bytecode or machine code.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  7. #7
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    Interesting. Almost makes me want to take Java off my "hate list"

  8. #8
    Registered User
    Join Date
    May 2003
    Posts
    1,619
    It can also optimize code based on runtime information - for example, it can inline virtual function calls because it knows the actual runtime type, or inline event/delegate code where the event handler may often not be bound to that event until runtime.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  9. #9
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    No embedded system JVM is doing any relevant dynamic profiling-based optimization that I've ever heard. They don't have the memory for that.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. compilation problem
    By zahid990170 in forum C Programming
    Replies: 4
    Last Post: 05-21-2011, 12:07 PM
  2. c compilation
    By herWter in forum C Programming
    Replies: 6
    Last Post: 07-28-2008, 01:51 PM
  3. Pro*C Compilation.
    By asif_oracle in forum C Programming
    Replies: 4
    Last Post: 04-01-2008, 09:41 AM
  4. Compilation Firewalls
    By George2 in forum C++ Programming
    Replies: 2
    Last Post: 03-16-2008, 05:01 AM
  5. PC RAM in Compilation
    By SlyMaelstrom in forum Tech Board
    Replies: 5
    Last Post: 05-21-2006, 06:03 AM