I never heard of anyone actually using Jazelle, though - I assume JIT ended up working better.
So on a smartcard ... write software in a (uncommon, and when compared with ARM which is a very "rich" assembly language) form of low-level instruction set, and pay both Sun and ARM top$ for the privilege - nevermind the likely "runtime" footprint far exceeding the 256kB RAM you planned for that 5$ card - why? Writing small singlethreaded software in anything that compiles down to a static ARM binary has been easy and quick enough that going off the ARM instruction set looked pointless for most. And learning which parts of "Java" actually worked in such an environment was hard, even (or especially?) for developers who knew (the strengths of) Java well. Because developers and specifiers expected "rich Java", and couldn't care less about the Bytecode. JITs later only hoovered up the ashes.
But the reality was that JIT allows code to get faster over time, as the JIT improves.
Things like Jazelle let chip manufacturers paper over a paper objection.
There were those "LISP machines" in the early 1980s but when Common Lisp was designed they made sure it could be implemented efficiently on emerging 32-bit machines.
Ehh .. PGO is only somewhat better for JIT than AOT. More often for purely-numerical code the win is because the AOT doesn't do per-machine `-march=native`. It's the memory model that kills JVM performance for any nontrivial app though.
Contrast this with the problem of specialization in AOT languages, which can easily result in bloated binaries (PGO does help here quite a lot, that much is true). For example, generics might output a completely new function for every type it gets instantiated with - if the function is not that hot, it actually makes sense to rather try to handle more cases with the same code.