1
0
mirror of https://github.com/php/php-src.git synced 2026-04-09 00:53:30 +02:00
Files
archived-php-src/Zend
Christoph M. Becker 8483a21f29 Fix several mostly Windows related phpdbg bugs
* Properly initialize PHPDBG_G(watch_tmp)

  Otherwise that may cause segfaults in ZTS builds.

* Deactivate potentially remaining watchpoints after REPL

  Otherwise the memory could still be protected, resulting in segfaults
  during shutdown.

* NULL zend_handlers_table after freeing

  As of commit 4130fe4[1], the `zend_handlers_table` is explicitly
  freed in the `zend_vm_dtor()`.  Since phpdbg (and maybe some other
  SAPIs) may restart the engine afterwards, we have to make sure that
  the table is also NULLed.

* Only set context option if there is a context

  In other words, we must not follow the null pointer.

* Cater to file handles without attached console

  File handles do not necessarily have an attached console (for
  instance, pipes do not), in which case `GetConsoleScreenBufferInfo()`
  fails.  In this case we set a default value (`40`) for lines like on
  other systems.

[1] <http://git.php.net/?p=php-src.git;a=commit;h=4130fe437a5db7ead1444d3748bd0fbad9829cb2>
2020-05-26 17:45:25 +02:00
..
2020-02-03 13:41:31 +01:00
2019-06-05 10:04:57 +02:00
2020-02-03 13:41:31 +01:00
2019-02-03 21:03:00 +01:00
2019-07-11 17:09:03 +02:00
2019-06-28 12:44:18 +02:00
2020-02-03 13:41:31 +01:00
2019-05-02 15:04:03 +02:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-03-12 00:35:35 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2020-05-15 11:04:40 +02:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2020-05-04 16:27:45 +02:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-05-29 11:48:41 +03:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-06-25 14:28:58 +02:00
2019-06-25 14:28:58 +02:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-04-07 15:55:34 +02:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-06-05 14:25:07 +02:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-12-11 12:21:49 +03:00
2019-02-03 21:03:00 +01:00
2019-02-03 21:03:00 +01:00
2019-07-13 01:58:01 +02:00
2020-02-03 13:41:31 +01:00
2019-07-24 19:51:56 +03:00
2019-07-24 19:51:56 +03:00
2019-02-03 21:03:00 +01:00
2019-05-31 12:20:21 +03:00
2020-03-31 10:22:55 +02:00
2019-07-17 03:50:47 +02:00

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