Difficulty

At my current level of skill and understanding, this feature would be impossible for me to implement on my own. It is just an introductory look at what the other sections will visually look like when they are also finished. I will not be implementing this feature.

Introduction

Multi-threading should not be allowed at the user level, but allow for sandbox threading. The PHP Engine should keep track of the creation of threads, protect against deadlocking, and control synchronization. This will abstract away the complexity and have PHP do all of the heavy lifting as well as protect the developers from themselves and harming the process the thread is in.

There are some architectures, both CPU and OS, that do not allow threading. There should be a fall back implemented in the virtual machine that still enables an environment functionally similar to threading. The fall back can be implemented like the ticks in the current PHP Engine or it could use a stack approach similar to operating systems.

The Engine could also track how efficient the system is and how well it would perform if it was single threaded. There should be a mix of allowing the developers to test and optimize on their own and tracking internally to help protect against slow scripts caused by wrong usage of this feature.

There should be internal reflection for threading to allow for tracking, overriding, and debugging. The reflection will track the time a thread takes, which threads and variables it is synchronized with, and how many times faults occurred. There should be functions for overriding whether or not the thread is still multi-threaded or if it creates an interprocess, or if it is instead acts like a single thread, when processed.

The multi-threading feature wouldn’t be useful, if the process shutdown and destroyed everything at execution. The feature would only be enabled for PHP environments that are already multi-tasked to keep the script from taking longer than it should.

Virtual Machine: Timing the Best Method

During runtime, the virtual machine can keep track of the time the script takes and switch between single threaded and multiple threads to get statistics on which would be the best method overall. After it figures which is the best method for the user, it can either log what it finds, allow for reflection to get the number, and then decide which is the best method to take. It would still work like the user expects, but allow for the virtual machine to decide which is the best method for the user.

This would add additional memory and processing overhead, so it could be disabled by those who already think that their script is optimized enough already. This adds another level of complexity to the feature and could introduce difficult to find and fix bugs. It should also be allowed to be overwritten by the user for those who know for a fact that the system doesn’t work that well for their script. The system won’t be able to work perfectly 100% of the time for every script.

This additional feature would be extremely useful for JIT or opcode cached environments where the script is stored in memory for extended periods of time. Keeping track of timing of various environments would allow for the system to rewrite itself to optimize the speed for the user. The abstraction would be such that the user wouldn’t be able to tell, except when the system fully realizes and optimizes itself and the script.

Keywords

The following sections will introduce additional keywords and syntax that will require that the flex and bison skeletons be updated to allow for this feature. This section will not be updated and will not be found here.

Different Methods for Creating Threads

The following parts will detail the various parts of this feature and will be split up to allow for better understanding on what the feature will involve.

1. Anonymous
   • Does not allow for returning to main thread or calling from the main thread.
   • Runs along side the main thread.
2. Named
   • Does not run unless called from the main process.
   • Can return data to the calling thread.
3. Shell
   • Allows for shell commands to be processed in another thread or process.
   • Allows for returning to the calling thread.
   • Allows for both anonymous and named shells.
   • It would replace functionality, most of the shell extensions, when implemented.
4. Interprocess
   • Replaces the current method of the Process Control extension with an easier to setup and create method.
   • Also will allow for connecting to other processes for passing data.

Possibly Related Posts:

• What is the Obituary Story
• Hashing Out Obituary Book Details
• English IV: Untitled Satire
• In Response to JIT Compilation
• PHP Opcode Series

Introduction

The PHP Opcode series will take a look at the theory and implementation of working with the Zend Engine in the specific areas of adding opcodes and enabling language features. The specific areas will be how it would look in the PHP language, how it would look as PHP opcodes, and how it would look as Assembler for looking at enabling JIT compiling later.

The posts will be researched and go through multiple drafts for professionalism before posting. In this hope, it will strive to enable discussion that isn’t flaming and collective of the topic at hand. For as much as I can achieve at my level of writing skill and researching the topic at hand.

(Honestly, I’m spending more time on these posts than I do on my school research papers… which is to still say that I am doing more than previous posts.)

Purpose

I want to add JIT compiling to the current Zend Engine and before I can do that I will have to learn how the Zend Engine works. The best way would be to read a book or learn from the minds that created it. There is a current lack of printed material on extending the Zend Engine and I’ll rather not bother the Zend Engine masters with my countless n00bish questions. I’ll wait to ask those questions for whenever I hit a road block or can’t find the answer myself.

I’m going to try to implement some of the easier features of the “Opcode Theory” part to learn how different areas of the Zend Engine work. I’ll also intentionally break the Engine and learn from there. Such questions as, “I wonder what would happen if I add this?” or “What if I change this to my own code.”

I’m tempted to rewrite the entire thing to my achieve my own goals, but that would negate the point of these exercises.

Not that I will implement all of the theory, but to think about how it would be possible. To learn how PHP uses Opcodes and how it can be improved and optimized by using more. By writing theory and how the current Zend Engine works, I can remember better and try to implement my ideas to see if they are possible.

Areas of Focus

There will be areas of focus with titles for keeping order of which post is for what.

• Opcode Theory
• Opcode Implementation
• Opcode Documentation

Opcode Theory

These posts will abstract out the problem and how it could look once implemented. From above, the sections will be PHP userland code, PHP Opcode, and finally how it would look as Assembler for JIT. The Assembler isn’t much use for the JIT, but it will help to think about solutions once JIT is finally implemented. The JIT and Assembler will achieve the same functionality of converting opcodes to machine code.

It would be nice to see it in action outside of PHP, using Assembler, before implementing the feature using the JIT library. Getting Assembler code to work against the Zend Engine and PHP will also be part of the Implementation, which is outside the scope of the Theory. It is just to say that the Theory part will have puesdo-Assembler code for how it might look.

I will not be implementing all of these theory posts and I will be lucky if I even implement one. My main purpose is learning enough of the Opcode parts of the Zend Engine to hook into and write a Zend Engine extension that enables JIT compilation. These side projects should help to learn enough to accomplish that much.

Opcode Implementation

Will document how well I’m doing implementing some of the theory and eventually the JIT feature for the Zend Engine. In the event that I do implement one of the features in the theory part, I will post what it finally looks like and how it works. These posts will also include the road and difficulties in implementing the features in the theory posts and eventually how it was done.

Opcode Documentation

I expect that I’ll learn a lot by the above mangling of the Zend Engine and picking at the minds and team behind the Zend Engine. Some things I will have to learn myself and I’ll post them in this heading to make sure that I’ll remember them when I come back after an extended break or two to work on other projects.

“Hmm, how did I do that one thing again? Oh yeah, I wrote about that!” and also to store help I will eventually (hopefully) receive from the PHP lists.

Possibly Related Posts:

• What is the Obituary Story
• Hashing Out Obituary Book Details
• English IV: Untitled Satire
• In Response to JIT Compilation
• Userland Multitasking: Introduction