Run-Time environments
(Your question seems to be about concepts and terminology. The meaning of termini depends on context - the quote is from a compiler writers' book. Not only are the authors entitled to a "compiler centric" view of things: that perspective is to be expected.)  

There are at least two "CS" interpretations to runtime environment.
 One is the process/OS level - some lump of hardware turned into a MINIX machine, an OS/400, QNX, z/OS, Multics one, defined in an applicable application binary interface (ABI).
At this level, memory usually gets allocated in segments or pages (taking care no information leaks). (In a conventional OS,) Requirements like amount and initialisation are taken from an "executable file" in an appropriate format.
It is a matter of definition whether "the compiler" is responsible for the generation of such a file from source code or just some intermediate code which may be executed by an interpreter, or statically analysed&amp;improved, turned into assembly language, assembled into an object file/module, linked with other modules.  

To me, the existence of a virtual machine is a philosophical question (as opposed to the existence of the computing hardware heating up my environment) - I take the pragmatic stance of accepting help, from a mere concept when that is what it is. Proponents of something like the Java virtual machine (JVM) (a popular target for compilers, btw.) are entitled to making the case for VM existence.  

Regarding exactly when the compiler does something, anything going on during execution of the compiler should be beyond doubt. A compiler-centric view may include anything from decisions made during the specification of the compiler (like row-major or column-major layout of two-dimensional arrays) up to and during the execution of the compiled program - anything not due explicitly to a specific part of the source code, but the language specification implemented by the compiler.

 This is the programming language level - what gets your main() running (and possibly constructors&amp;co. of statically allocated objects before that), that Begin…End;-block implicitly prefixed with Simula - you name it. It takes care of memory(/address) allocation (and possibly initialisation) for a subroutine call stack (per coroutine/thread), "statically allocated" program data (those objects named in the source program - on behalf of the program source code/the coder/the one who started the program), "automatically allocated" space (e.g., for "local" variables in potentially recursive subroutine calls), "dynamically allocated" space (e.g. objects for linked data structures. "dynamically": as need arises during program execution, a "program request" for (memory for) another object may lead to the language runtime environment requesting more memory from the OS - often, the RTE manages a memory pool for smallish requests and makes largish ones to the OS).
"The compiler" decides about memory layout for multi-dimensional arrays.
It arranges access to machine code for the "runtime library" - with OS support more often than not.
In all, a Forth machine, a Java, Fortran, Beta one.  

Note that


the paragraph quoted does not say the compiler [executes] the code
creates and manages needs interpretation/leaves room for it
one resource managed by one authority doesn't preclude the same resource being managed by another one - expect conflicting responsibilities handled usefully.