34 ms·
It likely counts the memory used by the JVM so it includes memory for the runtime, JIT, initial heap allocation, etc.
by vbsteven 5y ago
It likely counts the memory used by the JVM so it includes memory for the runtime, JIT, initial heap allocation, etc.
- jhgb 5y agoAlso both bytecode and the native code generated from bytecode are in memory at the same time, aren't they?
- vbsteven 5y agoYes, but it's more nuanced then that. If I remember correctly the bytecode is interpreted and executed by the runtime. This means the bytecode is fully in memory as bytecode when the jvm loads .class files. The native code for the JVM interpreter and runtime execution is also present in memory. At this point execution happens without "duplicate code" in memory. Note: the JVM could compile the bytecode fully into native code before execution but that's an implementation detail for a specific JVM implementation. Then we add the JIT. The JIT will notice hot paths during interpretation/execution and compile a method to native code and inject it so it calls the jit_native version instead of the bytecode_interpreted version. The JIT does not overwrite original bytecode but stores the compilation result separately. So to come back to your statement "both bytecode and native code generated from bytecode in memory at the same time": yes, but only for the JIT-compiled hot paths. This to me is the "power" of the JVM + JIT. Run interpreted bytecode and compile to native for the hot paths.