Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75063
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain microsoft.com designates 207.46.163.208 as permitted sender)
To: PHP Internals <internals@lists.php.net>
Thread-Topic: Q: How to handle zend_op_array.scope and zend_op_array.prototype
 in opcode cache?
Thread-Index: Ac+P0wFH3ht7EoAbSu+EG3YCkgzx/Q==
Date: Tue, 24 Jun 2014 19:08:48 +0000
Message-ID: <d052385a3c8e4cc3a56675e40dad84f5@BLUPR03MB421.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Q: How to handle zend_op_array.scope and zend_op_array.prototype in
 opcode cache?
From: ericsten@microsoft.com (Eric Stenson)

PHP Internals folks--

I'm working on the opcode cache part of Wincache, and I believe that Wincac=
he isn't properly handling the scope and prototype fields of the zend_op_ar=
ray struct when copying it into shared memory. =20

I tried looking at the Zend Opcache code to figure out what The Right Way(T=
M) to handle these fields, and I'm curious about how these fields are used =
by the Zend engine.

From what I can tell, Zend Opcache has a per-process HashTable where it kee=
ps track of which items is has copied into shared memory (xlat_table).

It looks like the xlat_table is cleared out before each compilation.  When =
persisting, Zend persists things in the following order:
  1. function_table
  2. class_table
  3. zend_op_array (for the main zend_op_array produced by compile)

My questions:
* Is there some guarantee that the scope and prototype on the main zend_op_=
array exist in the function_table and class_table for the compilation?
* Does the scope and prototype fields really matter for the main zend_op_ar=
ray?  Wincache has been setting them to NULL since day 1, and everything se=
ems to work just fine...
* The xlat_table key is a ulong.  Zend Opcache uses the pointer of an objec=
t as the key.  On Windows, a ulong is 32 bits.  How does this even work on =
an x64 Windows box?

Thx!
	--E.