2014.11.28. 9:24 ezt írta ("Dmitry Stogov" <dmi...@zend.com>):
>
> On Fri, Nov 28, 2014 at 7:33 AM, Xinchen Hui <xinche...@zend.com> wrote:
>
> > Hey:
> >
> > On Fri, Nov 28, 2014 at 1:27 AM, Dmitry Stogov <dmi...@zend.com> wrote:
> > > Hi,
> > >
> > > I'm working on call/return sequence optimization. As part of this work
> > I'm
> > > minimizing the size of call frame (zend_execute_data) and number of
> > > read/write operations on call/return.
> > >
> > > Could you please take a look into the patch that removes EX(scope)
> > > https://gist.github.com/dstogov/5ad50d582346385d587e
> >
>
> committed.
>
> > All phpt tests are passed, but I'm not completely sure about one line -
> > >
> >
https://gist.github.com/dstogov/5ad50d582346385d587e#file-ex_scope-05-diff-L193
> > >
> > > On the other hand I can't imagine what it may break.
> > neither do I.
> >
> > >
> > > Matteo, can you please run your test suites with this patch.
> > >
> > > PS: I'm also going to:
> > > - pack EX(num_args) into reserved space of EX(This)
> >
>
> done.
>
>
> > > - try to get rid of EX(frame_info)
> >
>
> done.
>
>
> > > - try to merge EX(called_scope) and EX(This). Only one of them
matters.
> > > - try to replace zval EX(This) with a pointer to zend_object
EX(object)
> >
> > Hmm, EX(This) is not like EX(object), it will be accessed by vm
> > handler: get_obj_zval_ptr_unused
> >
> > it suppores to return a zval * there. if EX(This) became a zend_object
> > *, then we may face different handlers for IS_UNUSED and other types
> > :<
> >
>
> Yes, I know. After the latest changes it doesn't make a lot of sense to
> replace ZVAL with ZEND_OBJECT*, because other data is already packed into
> the same ZVAL and it won't save any memory.
>
> Also zend_execute_data structure is aligned on zval boundary (16 bytes),
so
> it makes sense to save another 16 bytes, but saving 8 bytes won't affect
VM
> stack memory consumption.
>
> Thanks. Dmitry.
>
Fyi this change broke phpdbg in master.
