6cc53981e5
While we don't need to give this method separate static vars, we do still need to perform an addref, as there will be a corresponding delref in the dtor. |
||
---|---|---|
.. | ||
tests | ||
bench.php | ||
LICENSE | ||
Makefile.frag | ||
micro_bench.php | ||
README.md | ||
zend_alloc_sizes.h | ||
zend_alloc.c | ||
zend_alloc.h | ||
zend_API.c | ||
zend_API.h | ||
zend_arena.h | ||
zend_ast.c | ||
zend_ast.h | ||
zend_bitset.h | ||
zend_build.h | ||
zend_builtin_functions.c | ||
zend_builtin_functions.h | ||
zend_closures.c | ||
zend_closures.h | ||
zend_compile.c | ||
zend_compile.h | ||
zend_config.w32.h | ||
zend_constants.c | ||
zend_constants.h | ||
zend_cpuinfo.c | ||
zend_cpuinfo.h | ||
zend_default_classes.c | ||
zend_dtrace.c | ||
zend_dtrace.d | ||
zend_dtrace.h | ||
zend_errors.h | ||
zend_exceptions.c | ||
zend_exceptions.h | ||
zend_execute_API.c | ||
zend_execute.c | ||
zend_execute.h | ||
zend_extensions.c | ||
zend_extensions.h | ||
zend_float.c | ||
zend_float.h | ||
zend_gc.c | ||
zend_gc.h | ||
zend_generators.c | ||
zend_generators.h | ||
zend_globals_macros.h | ||
zend_globals.h | ||
zend_hash.c | ||
zend_hash.h | ||
zend_highlight.c | ||
zend_highlight.h | ||
zend_inheritance.c | ||
zend_inheritance.h | ||
zend_ini_parser.y | ||
zend_ini_scanner.h | ||
zend_ini_scanner.l | ||
zend_ini.c | ||
zend_ini.h | ||
zend_interfaces.c | ||
zend_interfaces.h | ||
zend_istdiostream.h | ||
zend_iterators.c | ||
zend_iterators.h | ||
zend_language_parser.y | ||
zend_language_scanner.h | ||
zend_language_scanner.l | ||
zend_list.c | ||
zend_list.h | ||
zend_llist.c | ||
zend_llist.h | ||
zend_long.h | ||
zend_map_ptr.h | ||
zend_modules.h | ||
zend_multibyte.c | ||
zend_multibyte.h | ||
zend_multiply.h | ||
zend_object_handlers.c | ||
zend_object_handlers.h | ||
zend_objects_API.c | ||
zend_objects_API.h | ||
zend_objects.c | ||
zend_objects.h | ||
zend_opcode.c | ||
zend_operators.c | ||
zend_operators.h | ||
zend_portability.h | ||
zend_ptr_stack.c | ||
zend_ptr_stack.h | ||
zend_range_check.h | ||
zend_signal.c | ||
zend_signal.h | ||
zend_smart_str_public.h | ||
zend_smart_str.c | ||
zend_smart_str.h | ||
zend_smart_string_public.h | ||
zend_smart_string.h | ||
zend_sort.c | ||
zend_sort.h | ||
zend_stack.c | ||
zend_stack.h | ||
zend_stream.c | ||
zend_stream.h | ||
zend_string.c | ||
zend_string.h | ||
zend_strtod_int.h | ||
zend_strtod.c | ||
zend_strtod.h | ||
zend_ts_hash.c | ||
zend_ts_hash.h | ||
zend_type_info.h | ||
zend_types.h | ||
zend_variables.c | ||
zend_variables.h | ||
zend_virtual_cwd.c | ||
zend_virtual_cwd.h | ||
zend_vm_def.h | ||
zend_vm_execute.h | ||
zend_vm_execute.skl | ||
zend_vm_gen.php | ||
zend_vm_handlers.h | ||
zend_vm_opcodes.c | ||
zend_vm_opcodes.h | ||
zend_vm_trace_handlers.h | ||
zend_vm_trace_map.h | ||
zend_vm.h | ||
zend_weakrefs.c | ||
zend_weakrefs.h | ||
zend.c | ||
zend.h | ||
Zend.m4 |
Zend Engine
Zend memory manager
General
The goal of the new memory manager (available since PHP 5.2) is to reduce memory allocation overhead and speedup memory management.
Debugging
Normal:
sapi/cli/php -r 'leak();'
Zend MM disabled:
USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cli/php -r 'leak();'
Shared extensions
Since PHP 5.3.11 it is possible to prevent shared extensions from unloading so
that valgrind can correctly track the memory leaks in shared extensions. For
this there is the ZEND_DONT_UNLOAD_MODULES
environment variable. If set, then
DL_UNLOAD()
is skipped during the shutdown of shared extensions.
ZEND_VM
ZEND_VM
architecture allows specializing opcode handlers according to
op_type
fields and using different execution methods (call threading, switch
threading and direct threading). As a result ZE2 got more than 20% speedup on
raw PHP code execution (with specialized executor and direct threading execution
method). As in most PHP applications raw execution speed isn't the limiting
factor but system calls and database calls are, your mileage with this patch
will vary.
Most parts of the old zend_execute.c go into zend_vm_def.h
. Here you can find
opcode handlers and helpers. The typical opcode handler template looks like
this:
ZEND_VM_HANDLER(<OPCODE-NUMBER>, <OPCODE>, <OP1_TYPES>, <OP2_TYPES>)
{
<HANDLER'S CODE>
}
<OPCODE-NUMBER>
is a opcode number (0, 1, ...)
<OPCODE>
is an opcode name (ZEN_NOP, ZEND_ADD, :)
<OP1_TYPES>
and <OP2_TYPES>
are masks for allowed operand op_types.
Specializer will generate code only for defined combination of types. You can
use any combination of the following op_types UNUSED, CONST, VAR, TMP and CV
also you can use ANY mask to disable specialization according operand's op_type.
<HANDLER'S CODE>
is a handler's code itself. For most handlers it stills the
same as in old zend_execute.c
, but now it uses macros to access opcode
operands and some internal executor data.
You can see the conformity of new macros to old code in the following list:
EXECUTE_DATA
execute_data
ZEND_VM_DISPATCH_TO_HANDLER(<OP>)
return <OP>_helper(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU)
ZEND_VM_DISPATCH_TO_HELPER(<NAME>)
return <NAME>(ZEND_OPCODE_HANDLER_ARGS_PASSTHRU)
ZEND_VM_DISPATCH_TO_HELPER_EX(<NAME>,<PARAM>,<VAL>)
return <NAME>(<VAL>, ZEND_OPCODE_HANDLER_ARGS_PASSTHRU)
ZEND_VM_CONTINUE()
return 0
ZEND_VM_NEXT_OPCODE()
NEXT_OPCODE()
ZEND_VM_SET_OPCODE(<TARGET>
SET_OPCODE(<TARGET>
ZEND_VM_INC_OPCODE()
INC_OPCOD()
ZEND_VM_RETURN_FROM_EXECUTE_LOOP()
RETURN_FROM_EXECUTE_LOOP()
ZEND_VM_C_LABEL(<LABEL>):
<LABEL>:
ZEND_VM_C_GOTO(<LABEL>)
goto <LABEL>
OP<X>_TYPE
opline->op<X>.op_type
GET_OP<X>_ZVAL_PTR(<TYPE>)
get_zval_ptr(&opline->op<X>, EX(Ts), &free_op<X>, <TYPE>)
GET_OP<X>_ZVAL_PTR_PTR(<TYPE>)
get_zval_ptr_ptr(&opline->op<X>, EX(Ts), &free_op<X>, <TYPE>)
GET_OP<X>_OBJ_ZVAL_PTR(<TYPE>)
get_obj_zval_ptr(&opline->op<X>, EX(Ts), &free_op<X>, <TYPE>)
GET_OP<X>_OBJ_ZVAL_PTR_PTR(<TYPE>)
get_obj_zval_ptr_ptr(&opline->op<X>, EX(Ts), &free_op<X>, <TYPE>)
IS_OP<X>_TMP_FREE()
IS_TMP_FREE(free_op<X>)
FREE_OP<X>()
FREE_OP(free_op<X>)
FREE_OP<X>_IF_VAR()
FREE_VAR(free_op<X>)
FREE_OP<X>_VAR_PTR()
FREE_VAR_PTR(free_op<X>)
Executor's helpers can be defined without parameters or with one parameter. This is done with the following constructs:
ZEND_VM_HELPER(<HELPER-NAME>, <OP1_TYPES>, <OP2_TYPES>)
{
<HELPER'S CODE>
}
ZEND_VM_HELPER_EX(<HELPER-NAME>, <OP1_TYPES>, <OP2_TYPES>, <PARAM_SPEC>)
{
<HELPER'S CODE>
}
Executor's code is generated by PHP script zend_vm_gen.php it uses
zend_vm_def.h
and zend_vm_execute.skl
as input and produces
zend_vm_opcodes.h
and zend_vm_execute.h
. The first file is a list of opcode
definitions. It is included from zend_compile.h
. The second one is an executor
code itself. It is included from zend_execute.c
.
zend_vm_gen.php
can produce different kind of executors. You can select
different opcode threading model using --with-vm-kind=CALL|SWITCH|GOTO
. You
can disable opcode specialization using --without-specializer
. You can include
or exclude old executor together with specialized one using
--without-old-executor
. At last you can debug executor using original
zend_vm_def.h
or generated file zend_vm_execute.h
. Debugging with original
file requires --with-lines
option. By default ZE2 uses the following command
to generate executor:
php zend_vm_gen.php --with-vm-kind=CALL