That being said, an overview of the renames planned would be helpful.
Okeedokee. After much discussion, we concluded that almost all names in the field of virtual machines are potentially problematic, because each name can mean different things in different contexts, and each name usually fails to say precisely what it means. For example, "JIT", which technically just stands for "Just In Time", could refer to any of a million different processes on a computer, including the "just in time" initialization of a data member in a class. Even if we allow that "JIT" implicitly refers to CPU-specific translation at runtime, making it less vague, "just in time" is still an inaccurate phrase, since function-at-a-time translation will translate unlikely basic blocks well before they execute -- if they execute at all. Even the phrase "virtual machine" is problematic, since the CPU itself is a kind of virtual machine. It's turtles all the way down. However, none of this changes the fact that we use certain names as terms of art all the time. So, we decided to shun the siren song of perfect, technically accurate naming, and settle on names that reflected our basic everyday thinking and speech. Therefore: * "Bytecode" Anything in JavaScript currently called "byte code" "opcode" "op code" "code" "bitcode" etc. we'll rename to "bytecode". We use one word with no camel case to indicate that the word is just jargon, and not a true compound word. It's not really one byte, but we're over that. We use this word every day when talking about our code, so we'll use it in our code, too. * "BytecodeGenerator" The class used to generate bytecode. "Generator" clearly indicates that the class outputs bytecode, whereas a name like "compiler" might mean that the class outputs bytecode, or it might mean that the class takes bytecode as its input. Also, we thought that names like "compiler" implied a larger suite of tools not included in this class. * "BytecodeInterpreter" The class that executes a program in bytecode form. We liked the symmetry with "BytecodeGenerator". We rejected names like BytecodeVM because we thought the name "virtual machine" was a little too vague, and it implied a larger suite of functionality not limited to this class. * "JIT" The class that translates a program in bytecode form to CPU-specific code. We rejected "BytecodeJIT" because we couldn't tell if a BytecodeJIT had bytecode as its input or its output. It's not symmetric with BytecodeInterpreter, but oh well. We liked "JIT" because we thought that interpreter vs JIT was a widely used and understood dichotomy. So we have this directory structure: bytecode -> generator -> interpreter -> jit -> sampler It bears mentioning that JavaScriptCore also contains a bytecode and a JIT for regular expressions, so the names above might be vague. We decided that the best solution was to treat regular expression functionality as secondary, giving classes related to it an extra prefix, or a different namespace. We also decided not to bother changing the nomenclature in PCRE, because PCRE is frozen in time. Also, PCRE hurts me in the brain. Many other small renames and file splittings are included in my patch, but they all tend to follow from these. The only substantial one I can think of is "__". Right now we have code like this: m_jit.movl_i32r(...) In this context, "m_jit" is a data member of "JIT", and an instance of the "X86Assembler" class. JIT::m_jit is weird, and calling an assembler a JIT is also weird. So, we opted to renamed "m_jit" to "m_assembler", and then for brevity, use a macro to replace "m_assembler." with "__", so you get this: __ movl_i32r(...) There are a few cases where this looks a little weird right now, but they're fixable. In general, this approach has worked well for other projects, so it will probably work well for us. Cheers, Geoff