David Wang:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 10/2/07, Wietse Venema <[EMAIL PROTECTED]> wrote:
> > Low-level implementation
> > ------------------------
> >
> > Taint support is implemented with some of the unused bits in the
> > zval data structure. The zval is the PHP equivalent of a memory
> > cell. Besides a type (string, number etc.) and value, each zval has
> > a reference count and a flag that says whether the zval is a reference
> > to yet another zval that contains the actual value.
>
> One possible problem area is that I'm using some of those very same
> bits for storing GC information. I'm not using very many, so there
> should be plenty to go around, but I'm currently using 3 bits in
> is_ref. 2 for the "color" (the GC state of the object) and 1 for
> whether or not the object is internally buffered. Just a heads up.
Did you read this?
Right now I am using seven bits, but there is room for more: 32-bit
UNIX compilers such as GCC add 16 bits of padding to the current
zval data structure, and this amount isn't going to be smaller on
64-bit architectures. If I really have to squeeze the taint bits
in-between the existing bits, the taint support performance hit
goes up to perhaps 2% in the macro benchmarks that I mentioned
above (but again, this number is barely above the 1-2% measurement
error, so don't take it too literally).
I found micro benchmarks in particular to be very processor dependent
(examples: empty loop, loop adding numbers, loop concatenating
strings; some tests were faster with taint, and some slower; change
the processor and some differences were the other way around). This
was with the same OS and the same compiler. Obviously such
differences are meaningless, and this is why I looked at macro
benchmarks.
Wietse
> Some details: I have the leftmost bit in is_ref be the indicator of
> is_ref. This is so I can test is_ref by just testing (z->is_ref >=
> 0x80). The reason I'm doing it like this is because I find that this
> comparison test is a lot faster than doing a bitwise test. I then use
> the other top three bits for what I need, so the bottom 4 bits are
> free.
>
> We really should conserve space, though. The biggest problem with
> increasing the size of the zval struct seems to be (incredibly) L1
> cache misses, as verified with cachegrind. Even increasing the size of
> the current zval struct by one byte has a measurable impact (my goal
> was to keep Zend/bench.php from showing any hit at all).
>
> David
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
