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.

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

It depends on the JITter. Some cache their results so it's only compiled the first time it's run. Some don't.

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.

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.

Another advantage is that stack-based bytecode (like Java's bytecode) is considerably more compact than register-based bytecode or machine code.

Interesting. Almost makes me want to take Java off my "hate list" :)

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.

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.