In Java the virtual machine executes your code, but C compilers generate code that the real machine executes. To be precise, in both cases your program ends up being converted into real machine code, but in the case of Java there’s a middle step of compiling to JVM bytecode.

So Java programs are converted to real instructions by the JVM when you load them, whereas C programs are already converted to real instructions by the compiler before they’re run.

Apart from machine code, there is no programming language in existence which executes directly on hardware, in the sense that you can’t feed it the literal source text. All real implementations must translate the source program into the language of the “machine”.

For some implementations, it’s translated statically. We usually call these implementations “compiled”. For others, it’s translated into some intermediate form, which is then translated dynamically as the program is run. We usually call these implementations “interpreted”. There is a continuum of possibilities between these, and even many modern CPUs do dynamic translation as part of its execution core.

Even when your program is statically compiled long before execution, unless you’re writing firmware, it’s rare that the compiled code runs directly on the bare metal with nothing supporting it. The operating system provides a virtual machine for user-space programs, often providing such features as the illusion that you have a CPU all to yourself. The illusion of a flat memory space which could be larger than the physical RAM attached to the machine is even called “virtual memory”.

On top of that, even when you’re programming in C, there is a C virtual machine! It is traditionally referred to as “the C runtime”, or CRT for short.

Because C is mostly translated directly into assembly/machine code well ahead of time (on some platforms, there may also be some threaded code, and that can be considered part of the virtual machine), the virtual machine usually only has to handle startup and shutdown.

Startup typically involves setting up the stack and heap; the operating system rarely provides these for you, and it’s the job of the programming language to provide these to the programmer. On some platforms there may be some initialisation of signal handling, setting up the “main” thread in a multi-threaded environment, running global constructors on the off chance that the program has been linked to C++ code, handling dynamically linked libraries, or there may be some processing required to set up argc/argv and envp. Finally, CRT transfers control to main.

As for shutdown, many operating systems can kill a process uncleanly, so shutdown doesn’t need to do very much. The main thing is to process atexit() calls for the case where the program does exit cleanly.