Perl virtual machine

The Perl virtual machine is a stack-based process virtual machine implemented as an opcodes interpreter which runs previously compiled programs written in the Perl language. The opcodes interpreter is a part of the Perl interpreter, which also contains a compiler (lexer, parser and optimizer) in one executable file, commonly /usr/bin/perl on various Unix-like systems or perl.exe on Microsoft Windows systems.

Implementation

Opcodes

The Perl compiler outputs a compiled program into memory as an internal structure which can be represented as a tree graph in which each node represents an opcode. Opcodes are represented internally by typedefs. Each opcode has next / other and first / sibling pointers, so the opcode tree can be drawn as a basic OP tree starting from root node or as flat OP list in the order they would normally execute from start node. Opcodes tree can be mapped to the source code, so it is possible to decompile to high-level source code.[1]

Perl's opcodes interpreter is implemented as a tree walker which travels the opcode tree in execution order from the start node, following the next or other pointers. Each opcode has a function pointer to a pp_opname function, i.e. the say opcode calls the pp_say function of internal Perl API.

The phase of compiling a Perl program is hidden from the end user, but it can be exposed with the B Perl module[2] or other specialized modules, as the B::Concise Perl module.[3]

An example of a simple compiled Hello world program dumped in execute order (with the B::Concise Perl module):

$ perl -MO=Concise,-exec -E 'say "Hello, world!"'
1  <0> enter
2  <;> nextstate(main 46 -e:1) v:%,{
3  <0> pushmark s
4  <__SUB_LEVEL_SECTION_1__gt; const[PV "Hello, world!"] s
5  <@> say vK
6  <@> leave[1 ref] vKP/REFC

Some opcodes (entereval, dofile, require) call Perl compiler functions which in turn generate other opcodes in the same Perl virtual machine.

Variables

Perl variables can be global, dynamic (local keyword), or lexical (my and our keywords).

Global variables are accessible via the stash and the corresponding typeglob.

Local variables are the same as global variables but a special opcode is generated to save its value on the savestack and restore it later.

Lexical variables are stored in the padlist.

Data structures

Perl VM data structures are represented internally by typedefs.

The internal data structures can be examined with the B Perl module[2] or other specialized tools like the Devel::Peek Perl module.[4]

data types

Perl has three typedefs that handle Perl's three main data types: Scalar Value (SV), Array Value (AV), Hash Value (HV). Perl uses a special typedef for the simple signed integer type (IV), unsigned integers (UV), floating point numbers (NV) and strings (PV).

Perl uses a reference count-driven garbage collection mechanism. SVs, AVs, or HVs start their life with a reference count of 1. If the reference count of a data value drops to 0, then it will be destroyed and its memory is made available for reuse.

Other typedefs are Glob Value (GV) which contain named references to various objects, Code Value (CV) which contain a reference to a Perl subroutine, I/O Handler (IO), a reference to regular expression (REGEXP; RV in Perl before 5.11), reference to compiled format for output record (FM) and simple reference which is a special type of scalar that point to other data types (RV).

stash

Special Hash Value is stash, a hash that contains all variables that are defined within a package. Each value in this hash table is a Glob Value (GV).

padlist

Special Array Value is padlist which is an array of array. Its 0th element to an AV containing all lexical variable names (with prefix symbols) used within that subroutine. The padlist's first element points to a scratchpad AV, whose elements contain the values corresponding to the lexical variables named in the 0th row. Another elements of padlist are created when the subroutine recurses or new thread is created.

Stacks

Perl has a number of stacks to store things it is working on.

Argument stack

Arguments are passed to opcode and returned from opcode using the argument stack. The typical way to handle arguments is to pop them off the stack, and then push the result back onto the stack.

Mark stack

This stack saves bookmarks to locations in the argument stack usable by each function so the functions doesn't necessarily get the whole argument stack to itself.

Save stack

This stack is used for saving and restoring values of dynamically scoped local variables.

Scope stack

This stack stores information about the actual scope and it is used only for debugging purposes.

Other implementations

There is no standardization for the Perl language and Perl virtual machine. The internal API is considered non-stable and changes from version to version. The Perl virtual machine is tied closely to the compiler.

The most known and most stable implementation is the B::C Perl module[5] which translates opcodes tree to a representation in the C programming language and adds its own tree walker.

Another implementation is an Acme::Perl::VM Perl module[6] which is an implementation coded in Perl language only but it is still tied with original Perl virtual machine via B:: modules.

See also

• Comparison of application virtual machines

References

1. "B::Deparse - Perl compiler backend to produce perl code".
2. "B - The Perl Compiler Backend".
3. "B::Concise - Walk Perl syntax tree, printing concise info about ops".
4. "Devel::Peek - A data debugging tool for the XS programmer".
5. "B::C - Perl compiler's C backend".
6. "Acme::Perl::VM - A Perl5 Virtual Machine in Pure Perl (APVM)".

External links

• The Perl internals: running stage
• Introduction to the Perl API
• The "B" op tree.