http://www.phparch.com \ May 2019 \ 33Internal Apparatus
Memory Abstractions
Edward Barnard
We normally don’t care about abstractions in software, because they exist to hide details we
shouldn’t need to care about. However, sometimes, we do need to know the detail. An essential
part of how PHP works involves memory management. This month we’ll see new ways to think of
memory itself; we’ll also introduce a learning tool we’ll be using in upcoming articles. We’ll be
simulating an ancient mainframe computer, and its hard-wired operator console, using modern
text messages.
Abstract and Concrete
All software is ultimately an abstrac-
tion. We have layers of abstractions
building upon yet more layers of
abstraction. We connect (or compose)
pieces together to create our software—
which can itself become an abstraction.
Abstractions are designed to hide the
details. These abstractions aim to make
it easier for you to get your job done.
We can read a row from a database table,
for example, without being concerned
about making a socket connection to
the database server or verifying digital
certificates.
It’s one of the reasons I’ve always
enjoyed scripting languages such
as Perl and PHP. There’s no explicit
compilation step as with C or Java
programming—write the code, and it
can be run as-is.
However, somebody had to write the
compiler/interpreter, or the operating
system, or the database server, or the
web server code. Someone had to look
underneath the current abstraction and
learn how that abstraction is imple-
mented.
In the PHP world we already do
this. We understand server request
and response. We make use of cookie
handling. We might not know the
server internals, but we have a good
idea of its purpose, its input and output,
its startup and shutdown. We have a fair
concept of its performance characteris-
tics.
What’s the purpose of a PHP variable?
It’s a way to remember, or keep track of,
a specific value. Variables have a scope.
If we need to keep track of that value
from one function (or method) to the
next, we can pass it along as an argu-
ment to the function call and return any
changes to the value.
If we need access to that variable from
anywhere, we can make it a “global”
variable. Doing this both helps us and
hurts us; it’s harder to test and validate
software that maintains global state.
Variables have a time aspect as well.
If the value must persist beyond the
current software’s execution (in PHP
terms, the current request), we can
persist the value as a cookie, in a data-
base table, in a file, in the PHP session,
and so on. We have numerous options—
but the abstract concept is “persistence.”
Thus far we have two abstract
concepts relating to memory. We have
“scope” and “persistence.” There’s a third
concept we don’t need to consider as
often: “performance.” Performance is
always a tradeoff between time and
space. An in-memory database or
message queue is faster than a system
where the database or message queues
are stored on disk. But the in-memory
database takes up more memory. An
in-memory database can also be lost
if someone powers-off the machine.
Something with a smaller memory
footprint is more performant in terms
of memory requirements, but far less
performant in terms of speed.
When dealing with computer hard-
ware and software, the same concepts
keep popping up decade after decade.
A historical perspective can be helpful;
on the other hand, it’s important to be
practical. Theory is of little use until it’sapplied! A bag of cement, for example,
is useful—in theory. However, it’s the
sidewalk, as a “concrete” implemen-
tation of cement, which is useful for
decades to come.
This month we’ll be learning theory
regarding memory abstractions. We’ll
be introducing a tool that I extracted
from computer gaming’s early days. We
won’t use the tool until next month, but
I hope the gaming backstory helps keep
things fun!Opportunity
What problem are we trying to
solve? Or, as the marketing team might
express it, what opportunity do we
hope to embrace?
With this internal apparatus column,
we’re aiming to bridge the gap between
software development in PHP, and
software development of PHP—that
is, to be able to work with the PHP
compiler itself. The PHP compiler is
open source—anyone is welcome to
contribute.
The “gap” comes from the fact that
many—perhaps most—people who
write PHP software do not also write C
code. The PHP compiler is written in C.
But we, of course, write PHP. That’s why
we are talking about the PHP compiler
(written in C) from a PHP perspective.
The opposite situation is equally
weird. Can you imagine a language
compiler entirely written in its own
language? The first time I encountered
such a beast (it was Burroughs Algol), I
just couldn’t figure it out. Which came
first, the chicken or the egg, so to speak?