when java jvm compiles bytecode, where does that code go in process space?

Question

When the jvm (hotspot in my case) permanently compiles certain code paths into machine code, where is that machine code being stored? in the .text segment of process memory? in the process's heap??

I am not talking about JITing. From my understandning, JIT will compile and run bytecode without ever saving the compiled code anywhere. But what about when the jvm is saving that code -- where in process space does it save it? ... as the comments and answers point out, everything I was asking for is, in fact, a part of JIT.

EDIT:

as per my comment below, the situation I'm specifically referring to is documented here as "Adaptive optimization": http://www.oracle.com/technetwork/java/whitepaper-135217.html#hotspot

Alcalde

When does the JVM produce compiled code other than during JITing? – Repetend

The JVM does not permanently compile to bytecode to native machine code. Thus it is not persistently stored anywhere. – Feinleib

@AlexanderBird: That is JITting. – Highstepper

Answer 1

Firstly, what you are describing is JIT - specifically how it works in Hotspot

To answer your question about where the code is saved at runtime - it's in the process heap and the pointers to the method code in the object's Klass file is updated to point to it. There's also something called OSR (on stack replacement) for compiling long running loops directly on the stack.

Repetend

Thank you for both answering my question and deciphering what I was trying to ask :) – Alcalde

Is the compiled code stored in the same "code cache" that this question talks about? If so, if I increase -Xmx, will that affect the code cache? – Alcalde

Yes it is and I think it would be best to use the explicit option mentioned in this post i.e. -XX:ReservedCodeCacheSize – Repetend

That's not quite true: the process heap is usually protected by OS from being executable. – Bandoleer

Answer 2

I haven't worked with production-quality VMs, but here are my five cents.

.text sections in Unix executables belong to the file which stores executable code; at run-time this file section is mapped to a memory area allocated by the system linker during program initialization, that's all (on Linux, you can see the sections layout in memory in /proc/$PID/maps).

As for JIT-compilation on Unix-like systems, I can only think of memory areas which have been allocated by mmap system call with PROT_EXEC flag enabled. This call is specified by POSIX standards and used by the Linux's system linker, ld.so, to load any native executable file into memory. This call can be equally used for allocating new executable memory areas at run-time.

The usual heap is often protected by OS/MMU from being executed, as any /proc/$PID/maps file suggests:

00dd4000-01292000 rw-p 00000000 00:00 0                  [heap]

here rw-p means that no data in [heap] can be executed (though, e.g., it is not the case with 32-bit x86 CPUs without PAE, they don't have hardware capability to prevent running some memory data as code), but can be read/written.

So a VM needs a dedicated memory area with code execution permission. Indeed, let's look for rwx memory areas in some java process memory layout:

# cat /proc/12929/maps | grep rwx        # I run a Java VM with PID 12929
f3700000-f3940000 rwxp 00000000 00:00 0  # - an unnamed executable & writable region

Then execution of native code is a matter of assembling JIT-compiled native code either position-independently (like shared objects code is compiled, with gcc option -fPIC) or using the address returned by mmap().

Bandoleer