The Different Meanings of “Runtime”

As someone in the field of programming languages, it a pet peeve of mine when people use the same term – “runtime” – to mean different things1:

  1. Time taken to execute a benchmark/workload/program, etc. This is the most common use of the term “runtime” since its use extends to outside the discussion of programming languages and into general discussions of tech.
  2. As an synonym of dynamic, that is to say, in contrast to static or “compile-time”. So “runtime type information”, for example.
  3. Language runtime. So your JVMs, CPython, etc.
  4. Runtime environment. This is broader than “language runtime” since it includes the OS, standard libraries, hardware resources, and language runtimes themselves. This meaning is rare and it is often the case that the term “runtime environment” is used in full.

Now, usually these can be interpreted with context, but, arguably, it still increases impedance when you are reading or discussing a technical topic with someone. There are cases, however, when it is ambiguous and you often have to dig deeper or interrupt someone’s flow to clarify what they mean:

  • “Scanning runtime (garbage collection) roots” can be an ambiguous phrase. Do you mean the roots which are dynamically present during execution? Or do you mean special roots which are part of the language runtime (such as those present in the code cache for OpenJDK)?
  • “Runtime object layout” is also ambiguous. Do you mean the layout the object will have dynamically at execution-time or the basic object layout definition in the language runtime?
  • “The program’s runtime is quite fast”. 99\% of the times this likely means that the program executes quickly, but I’ve seen instances where they actually meant the language runtime itself is fast.
  • “Android Runtime ". This one, personally, hurts the most. Google (Scholar) searches for "Android Runtime benchmarks", for example, will essentially give arbitrary results that happen to contain the term "runtime" (in any one of its meanings, most often the first one) when we clearly want benchmarks for the Android Runtime (ART) itself. Adding "ART" to the list of keywords barely seems to help.

I am generally not a pedant, but I think there is value in being pedantic during technical discussions as presenting your ideas clearly is better for everyone involved in the conversation. It is also often exasperating when you are trying to do keyword searches and you keep getting results which confuse the sense of the term “runtime” with one of its other meanings (like I mentioned above). There is value in having different terminology for the different senses of the term “runtime”.

To avoid confusion, our lab differentiates between these different meanings, in both prose and conversation:

  1. For the first definition of “runtime”, we use “run time” or preferably “execution time”. Using “execution time” completely removes the ambiguity and while more verbose, it is arguably clearer especially during a conversation.
  2. For the second definition, we use “run-time”. This also makes it symmetric to “compile-time”. “Dynamic” can also be an appropriate synonym.
  3. We just use “runtime” for the third definition. During conversations, we often use “language runtime” in full to differentiate it from the above meaning.
  4. We use the term “run-time environment” in full to avoid any ambiguities. “Execution environment” is also an appropriate substitution. It is convenient that this term is the rarest in our day-to-day work since we are most often dealing with language runtimes and not the broader scope, so the extra verbosity is generally not an issue.

That’s not to say I haven’t had a fair share of discussions which confuse one of the meanings of “runtime”. But just being aware of the distinctions has greatly improved our technical communication skills.

  1. At least it’s better than “tabled” in American vs British English. ↩