On Sat, Oct 04, 2003 at 12:13:12PM +0200, Andi Gutmans wrote:
> At 08:16 AM 10/4/2003 +0900, Moriyoshi Koizumi wrote:
> >Andi Gutmans <[EMAIL PROTECTED]> wrote:
> >
> >> Hi,
> >>
> >> I don't like this patch because already the gc is a very sensitive
> >> mechanism and we're not allowed to collect too much or too little at any
> >> given time. Your patch can easily lead to too much being collected before
> >> previous zval's are freed which can lead to problems (this mechanism was
> >> refined a couple of times due to such problems).
> >> The only real solution I can see is to nuke the garbage completely. I
> >> already have a rough idea of how to do it but it requires quite a lot
> >of work.
> >> BTW, I didn't quite understand the bug report 25543. It doesn't seem to
> >be
> >> very well written (I know it's not you :)
> >
> >Actually the PR number is 25547 :) Anyway, I don't think my patch is so
> >harmful because the pointer to a zval (semantically a container of a zval
> >instance) that has been created at certain znode construction
> >is supposed not to be destroyed during an atomic operation, by which I
> >mean a single opcode processing. That's why I named them zend_*_atomic().
>
> OK, that explains why the bug report didn't seem to have anything to do
> with this problem :)
>
> I disagree. It definitely has potential to be harmful because the garbage
> isn't running every opcode like it should. At least that's what I figured
> from reading the patch.
on a sidenote - i once played around by just adding this
garbage to a linked list and only reclaim it inside emalloc.
that way we don't need to clean it after every op.
this won't fix the 25547 but it would make fixing it less
costy as the gc would not happen as often, and adding code to
it would not slow down the executor.
re,
tc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
