I think, op_array->type and op_array->fn_flags can't be reused.
Also, usage of op_array->run_time_cache is safer (I remember, I saw some
SIGSEGVwith your patch and opcache.protect_memory=1)
Got it. Does run_time_cache vary when caller is different? maybe I can
use the first 2 bytes for the accessor information.
Cheers, Yo-An
did you see my patch? It already uses run_time_cache of calling op_array to get getter property offset.
It's also possible to "allocate" slots in "run_time_cache" of caller op_array at compile_time, increasing op_array->cache_size. (see zend_compile.c), but I don't see a big reason to do it.
Thanks. Dmitry.
Yeah I know. I've saw that yesterday.
Hi Dmitry,
How's it going?
I traversed the code of opcache extension, and just found the FUNC_INFO
related macros. I guess the accessor information is more like an entry
that should be put in the function info.
Or... maybe we shall move the function info related functions into the
core? since we might have some optimization based on the function info
instead of optimizing opcode only in the future.
And I think the function info we pre-processed in the compile-time would
help JIT to compile the opcode a lot.
By the way, would you mind to let me know the plan of implementing the JIT
compilation in PHP? I saw your zend-jit branch is using LLVM as the backend.
In my experience, LLVM compiles large code a lot of slower. what do you
think of using DynASM as the JIT backend?
V8 compiles ast nodes into native code directly without
interpreting/translating the op codes, I don't know if it's a good approach
to try. your thoughts?
Cheers, Yo-An
Hi Yo-An
Hi Dmitry,
How's it going?
I traversed the code of opcache extension, and just found the
FUNC_INFO related macros. I guess the accessor information is more
like an entry that should be put in the function info.
That, FUNC_INFO is available only during optimization (it's especially
used in inter-procedure data-flow pass).
Or... maybe we shall move the function info related functions into the
core? since we might have some optimization based on the function info
instead of optimizing opcode only in the future.
We consider, possibility of moving the whole Optimizer into Zend, but it
won't change a lot, because expensive optimization make sense only with
opcache (when script is optimized once and executed many times).
And I think the function info we pre-processed in the compile-time
would help JIT to compile the opcode a lot.
Of course. Actually, the new optimization passes introduced in "master"
branch came from our zend-jit project and reused to generate LLVM code.By the way, would you mind to let me know the plan of implementing the
JIT compilation in PHP? I saw your zend-jit branch is using LLVM as
the backend.
We don't have special plans yet. We are going to work on JIT later, and
now we mainly work on interpretative optimizations.
Once we start JIT, it's going to be much difficult to change something
in VM...In my experience, LLVM compiles large code a lot of slower. what do
you think of using DynASM as the JIT backend?
Right. LLVM is not suitable for JIT. It's a compiler without front-end part.
We will probably go with DynASM from LuaJIT, Low Level Interpreter from
WebKit or our own similar approach.
V8 compiles ast nodes into native code directly without
interpreting/translating the op codes, I don't know if it's a good
approach to try. your thoughts?
In my experience, this approach doesn't work well especially with big
PHP applications.
Thanks. Dmitry.
Cheers, Yo-An
We consider, possibility of moving the whole Optimizer into Zend, but it
won't change a lot, because expensive optimization make sense only with
opcache (when script is optimized once and executed many times).
Do you (or the team?) prefer to keep the JIT implementation as an extension
or integrate the JIT implementation into the Zend core?
Thanks, Yo-An
Or... maybe we shall move the function info related functions into the
core? since we might have some optimization based on the function info
instead of optimizing opcode only in the future.We consider, possibility of moving the whole Optimizer into Zend, but it
won't change a lot, because expensive optimization make sense only with
opcache (when script is optimized once and executed many times).
Is this something I can help? I mean, moving the core of func info into the
core.
I think I might need to postpone the accessor optimization before the
func_info is integrated into the core since it's the best place to store
the accessor information.
Best Regards,
Yo-An Lin