As far as I know a JVM can work in different ways:
Interpreter: Runtime translation from bytecode to native code over and over again.
Just in time compilation: Compile parts of bytecode into native code at runtime when needed. Keeping the compilations. Performance overhead / penalty for compilation. Introduces possibilities for adaptive optimization at runtime which is not possible with static ahead of time compilation.
Hotspot: Only frequently executed parts get JIT compiled. The rest gets interpreted.
Now GraalVM can compile do ahead of time compilation of bytecode into native code.
Is it possible to compile bytecode ahead of time and do adaptive optimization on hotspots (in general and with GraalVM in special)?
[Clarification] I don't mean to AOT compile parts of the bytecode to native code and leave other parts as bytecode to perform hotspot JIT compilation of them at runtime. This is what IBM's Excelsior Jet Java implementation seems to do, what I have read so far. I mean AOT compile the whole bytecode and replacing the hotspots parts at runtime with adaptively optimized recompilations of hotspots. Which requires connecting / inserting the optimized code properly into the existing AOT compiled code. [/clarification]
I don't know what information is needed for recompilation of hotspots with adaptive optimization at runtime . Is the bytecode needed to do it? This would mean a higher memory consumption as cost for higher performance.
I am not an expert to this, so please tell me if any assumption are wrong.
Refer to JEP 295. It mentions different AOT modes, including tiered AoT which delivers C1-compiled code with profiling instrumentation which can then optimized with C2 at runtime.