This document contains a list of terms, abbreviations, and acronyms that you may come across either in this guide or in the HHVM source code. Don't worry if none of the definitions mean anything to you yet; it may make more sense to revisit this page as needed once you've read some more of the guide.
The terms in this section are specific to HHVM, Hack, or PHP. Concepts that apply more generally are listed in the next section.
The Alternative PHP Cache was originally added to PHP as a cache for compiled bytecode, to reduce the overhead of loading a program's source code with every request. It has since been replaced, but HHVM still supports it as a process-global hash table, used to share data between active requests and/or cache data to be reused by later requests.
BOLT is a binary optimizer, developed by Facebook to optimize the performance of large applications.
Function parameter info and corresponding regions in the bytecode. Described in detail in bytecode.specification.
The Hack Compiler, HHVM's new frontend (as of mid-2018). A parser and bytecode emitter written completely in OCaml.
HipHop assembly: a human-readable and -writable representation of HHBC, HHVM's bytecode.
HipHop bytecode, HHVM's custom bytecode. Described in bytecode.specification.
HopHop bytecode-to-bytecode compiler. Our static analysis engine that performs a number of offline optimizations on bytecode.
HipHop intermediate representation, the primary IR in HHVM's JIT. Described in ir.specification.
HipHop for PHP, a transpiler from PHP to C++ and HHVM's predecessor. A large part of HHVM's runtime is inherited from HPHPc.
HHVM native interface. HHVM's mechanism for calling native code from PHP (name inspired by JNI).
The request data segment, defined in runtime/base/rds.h is a form of thread-local storage, used to hold information that can vary between PHP requests, like the definitions of classes and functions. The target cache is a collection of request-local caches used by the JIT that live in RDS.
HHVM stores bytecode in a cache we call the repo, short for "repository". Repo authoritative is an execution mode in which HHVM assumes that no code exists outside of what's already in the currently-loaded repo, allowing much more aggressive optimizations.
The block of memory where HHVM stores JIT-compiled code.
Translation cache address: a pointer to code or data in the translation cache.
Translation cache printer: a tool for inspecting the code generated by HHVM, optionally annotated with performance events.
A region of bytecode used as the basic unit of compilation in some modes of HHVM's JIT. No larger than a basic block.
Virtual assembly, our low-level intermediate representation. Positioned between HHIR and machine code.
Extended linear scan, the algorithm used by our register allocator.
If you're new to compilers, performance-sensitive applications, or just curious, you may want to skim through the following terms:
- ARM: A family of CPU architectures. In the context of HHVM: AArch64, the 64-bit version of ARM.
- AST/abstract syntax tree
- Bytecode
- Basic block
- CFG: control flow graph or context-free grammar (nearly always the former here).
- Compilation unit/translation unit
- COW/copy-on-write
- CPU cache. Also d-cache, data cache, i-cache, instruction cache.
- IR/intermediate representation.
- FP/frame pointer.
- ICF/identical code folding: a compiler/linker optimization that detects and de-duplicates identical blocks of code.
- TLB/iTLB/dTLB
- Bytecode interpreter
- JIT/just-in-time compilation
- Leaf function: a function that calls no other functions; a leaf node in the control flow graph.
- NUMA/non-uniform memory access
- PGO/profile-guided optimization
- RSS/resident set size
- SP/stack pointer
- x86: A family of CPU architectures. In the context of HHVM: x86-64, the 64-bit version of x64.