Also, add comments on the other ones I've found for ->set().
The biggest thing here is sorting out static property initializers
(probably the answer there is to make them not even use arrays).
Reviewed By: @edwinsmith
Differential Revision: D972067
This diff reworks the PHP extension compat layer to be more robust by
taking steps to reconcile the difference between mainstream PHP's way and
HHVM's way of representing program values and operating on program values.
This includes the shape of the object graph in the heap (what points to
what), how refcounting is done and how "reffiness" is handled, how copy-
on-write semantics are honored, and how values are stored into arrays.
One of the core ideas here is that HHVM supports "boxing" a program value
via the RefData type and that there's a reasonably clean mapping between
PHP's object graph and HHVM's object graph (when HHVM program values are
"boxed") that maps PHP "zval" objects onto HHVM RefData objects. For the
purposes of a compat layer for PHP extensions, it makes sense to use
RefData to represent "zvals". Of course, it is unreasonable to box every
program variable in HHVM since this would hurt performance. However, we
can make things work by boxing program values lazily as needed in the
right places to ensure that Zend PHP extensions only deal with boxed
values. Along the way I also fixed a bug where we were leaking all of
the arguments that were passed to Zend PHP extension functions.
The next issue involves "reffiness". At present, HHVM RefDatas are treated
as "reffy" when their refcount is 2 or greater, while Zend PHP zvals have a
separate flag (independent of the refcount) that indicates whether they
should be treated as "reffy". Zend PHP extensions are capable of setting
two or more program variable to point to the same zval where the zval's
"reffy" flag is set to false. In such cases, the program variables share
the zval using copy-on-write semantics, where the zval must be copied
before making a modification. To make this work, we need to change RefData
somehow so that we can keep track of whether copy-on-write is needed when
the refcount is 2 or greater. Adding "reffy" flag directly poses some
challenges in terms of performance, because it means that when a value's
refcount decreases from 2 to 1 we'll need to make sure the "reffy" flag
gets cleared. I was able to avoid this by adding two flags (m_cow and m_z)
and creating a scheme that maps the 3-tuple (m_count, m_cow, m_z) to the
2-tuple (realRefcount, reffy). Under this scheme decRef continues to work
as it does today, decrementing the m_count field and calling a helper
m_count reaches zero. Another neat thing about this scheme is that m_cow is
set to 1 iff copy-on-write would be required before modifying m_tv. (NOTE:
This diff does not implement copy-on-write yet for these cases, it will be
addressed in a later diff.)
Another issue is the relationship between strings/arrays and the
zvals/RefDatas that point to them. Under Zend PHP, it is assumed that a
zval exclusively owns the string or array and that nothing else points to
the string/array. A consequence of this is that Zend PHP extensions do not
perform any copy-on-write checks with the string or array's refcount before
modifying the string/array. HHVM on the other hand supports sharing strings
and arrays between multiple RefDatas and/or program variables. Thus, we
need some way to protect against Zend PHP extensions modifying a string or
array when its refcount is 2 or greater. This is achieved by putting checks
in the right places to lazily make a copy of the string or array (when
refcount >= 2) so that Zend PHP extensions only deal with strings and
arrays with a refcount of 1.
Finally, the Zend PHP APIs for adding values to an array are a little
different. Zend PHP extensions pass a zval to the API, and the appropriate
array slot is set to point at the zval. The API does not increment the
zval's refcount; it is the caller's responsibility to do this is needed.
New APIs were added to HphpArray to address this need.
With this in place, the next things to go after would be (1) Fixing up how
the Zend compat layer deals emulating Zend PHP string macros and
operations, this may require adding a new KindOfZStr type if StringData
can't be adapted without hurting HHVM performance; (2) Adding checks in the
right places to make a copy of a RefData if m_cow is 1, I've found most the
places where this is needed and it doesn't look like these checks will
noticably hurt performance; (3) improving support for resource types and
object types defined by Zend PHP extensions and interoperability with HHVM
extension classes, HHVM resources, and user-defined pure-PHP classes.
Reviewed By: @ptarjan
Differential Revision: D966781
We need to create the catch trace before we pop the object,
since we're throwing with the marker set to before this instruction
has started. Also it needs Refs, because it can invoke the autoload
map code.
Reviewed By: @ottoni
Differential Revision: D970481
Was hoping to catch a bug from D891329. Only caught a benign
use-after-pop of an ActRec in the unwinder. Maybe worth it anyway?
Reviewed By: @edwinsmith
Differential Revision: D907772
Gets HphpArrays into a flat mode using MM().objMalloc()
instead of SmartAllocator. Various optimizations were needed to the
Make functions to get this to work out ok. Growth still creates a
non-flat HphpArray (leaving a PromotedPayload behind so we know how
big the original allocation was).
Reviewed By: @edwinsmith
Differential Revision: D969431
Currently, a call to an async function returns a (Continuation)WaitHandle
object but the excution of the function body doesn't start before await
(or join()) on the WaitHandle is called. This changes it to start the
execution immediately and the control is returned to the caller only
after it's blocked.
Differential Revision: D946914
Aside from instance bits this is pretty straight forward.
Most of the other friends were just directly accessing members instead
of using accessors.
Differential Revision: D953599
This diff fixes some bugs with invokeFunc() and invokeFuncFew(), it removes
some dead code, and it converts more places to use cellDup() instead of
tvDup().
invokeFunc() had a bug where the VM stack did not get cleaned up properly
when a warning is raised and the user error handler threw an exception.
This diff adds a catch clause that will perform the appropriate cleanup and
then rethrow the exception.
invokeFuncFew() had a bug where in some cases it would pass a parameter by
reference when the callee required that the parameter be passed by value.
This was happening because TypedValues that were KindOfRef would get copied
onto the VM stack using operator=, and nothing was checking whether the
callee required the parameter to be passed by value. This diff fixes the
issue by reworking invokeFuncFew() and callers of invokeFuncFew().
Differential Revision: D949251
We currently don't have a way to type XHP's {} operator (i.e. to type $foo in
function ($foo) {
return <div>{$foo}</div>;
}
An XHPChild interface should solve this issue by having a type which is compatible with arrays, strings,
ints and doubles. We can then modify www to have :x:base implement XHPChild.
To me, this seems like the right step to get rid of the Xhp special casing.
Differential Revision: D886565
Translator modularization. Mostly mechanical code motion,
with addition of some documentation and better logging (disasm
support, etc). It's possible that the set of stubs for ARM vs x64
might not be exactly the same eventually, but it might, so for now
this is layed out with the assumption that a future
unique-stubs-arm.cpp will populate the same list of stubs. (I also
tried drawing the line on a per 'stub group' basis, but too many stubs
have tricks about layout and it seemed hard to predict whether that
would commonize anything other than the function call loop, so we can
do it later as needed.) Also rename the JIT::CodeGenHelpersX64
namespace to JIT::X64.
Differential Revision: D942874
evalPHPDebugger catches and suppresses all exceptions except debugger exceptions. Hence the catch clauses that follow its only call site are dead code, except for the catch all, which seems just wrong to me since it suppresses Debugger exceptions that are explicitly propagated by evalPHPDebugger.
Differential Revision: D945652
The code to print out the result of the expression following the = command has moved from inside the resulting eval block, to outside it in the debugger code itself. Hence, if the eval block fails, the value of $_ now prints out and this is confusion because it is the value that a previous = command put in there. With this change the eval block first unsets $_, so that the subsequent print value code will do nothing in the case of a failure.
Differential Revision: D944120
fCallArrayhelper smashes its return address, leading to
return branch mispredictions until we return enough times to get back
on track. Rewrite it as an asm stub so it can make a tail jump and
pop the proper return ip into the ActRec.
Differential Revision: D941930
The C++ vtable pointers and the m_cls pointers in ObjectData are
redundant for C++ extension classes; they both indicate the ObjectData's
dynamic type.
This diff gives ObjectData the same treatment that the ArrayData
hierarchy got, replacing virtual functions with manual dispatch based on
attributes and m_cls. We can't do direct comparison against m_cls,
because of inheritance, except when we know inheritance is not in the
picture.
The vtable isn't gone yet, because I need to do something about C++
destructors, which still require virtual dispatch. That's going to
require a lot of grunt work, so I wanted to put this diff up to keep
that stuff separate.
I did, however, make ~ObjectData non-virtual and try to compile, to
flush out all the dynamic_casts of ObjectData.
- The type-casting functions and clone() are pretty straightforward. The
only trick is that specialized clone() functions now have to call
cloneImpl() instead of the base class' clone(), otherwise infinite
recursion. I added an ObjectData attribute to indicate whether clone()
is special.
- t___{sleep,wakeup} didn't even need to be virtual, it turns out.
ObjectData's implementation goes through the normal PHP-method lookup
path, which effectively does virtual dispatch and routes us to any
specialized implementations anyway.
Differential Revision: D940852
function foo($bar, $baz) { }
foo();
Currently raises two errors:
foo() expects exactly 2 parameters, 0 given
foo() expects exactly 2 parameters, 1 given
Only the first of these is either meaningful or correct.
Stop reporting once we've raised it.
Differential Revision: D939810
If re-entry triggers stack overflow, there is no FCall or FCallArray,
so the code to find the pc in REQ_STACK_OVERFLOW would fail. If it
managed to get through there, it would then try to DecRef the contents
of an ActRec, sometimes causing it to DecRef a Func.
In addition, if a "leaf" function resulted in re-entry we didn't
necessarily check the stack.
Differential Revision: D936843
Since D898769, all locals in generator bodies have the same ids
as in the corresponding 'create generator' methods, so the mapping
between these ids is no longer needed.
Differential Revision: D932354
fast absolute value computation and related optimizations
implemented Abs in interpreter
implemented Abs in codegen
added const folding for abs
updating docs
adding new test for abs()
Differential Revision: D896037
- segfault handler never panned out and has been off for 1.5
years; cheaper to resurrect later from git than refactor to take it out
of tx64
Differential Revision: D922900
We should only call values() when we absolutely have to (magic calls where the array is not a vector)
Differential Revision: D920504
Blame Revision: D917994
- Eliminate Util::safe_strerror and use folly::errnoStr instead since the former is less safe as it doesn't preserve errno
Differential Revision: D920282
Test cases inspired by zend test bug35239.phpt. I think
there are other cases where SETOP_BODY should be SETOP_BODY_CELL, but
I looked at them mainly to see if they would crash, not if they were
optimal. (Except I changed SetOpL which seemed to be doing tvToCell
twice for no reason.)
Differential Revision: D910025
This is a step toward having StringData take control over how
it talks to the smart allocator based on its constructor parameters.
For now nothing is done to prevent allocation without going through
the new proxy function, but the nested allocator type is renamed to
prevent adding new uses of NEW or DELETE.
Differential Revision: D907959
The units that result from Eval code injected by the debugger should always be interpreted because they are used once only, however, any code invoked by these units should be JITtable. This diff moves the test for disabling the JIT from VMExecutionContext to Translator::isSrcKeyInB. It also fixes a cut&paste error that inverted the logic for Unit::isInterpretOnly().
Differential Revision: D913723
Blame Revision: D904873
The PHPUnit test suite calls get_defined_constants(true), for categorization. We threw. Now we don't. Now we actually do something sort of correct, but not fully correct. We have a "user" and "core" constant categorization. Function cleanup and consolidation. That's good. But Zend categorizes even more into extensions. This is a first step. And two (2) tests now move from zend/bad to zend/good.
Differential Revision: D909942
A number of debugger commands end up doing an eval inside the VM. These eval's are ad-hoc and are performed in human time scales. There is no need to cache them. Consequently, call compile_string directly, rather than call it via compileEvalString (which does caching). Also make sure that the result of compile_string is always interpreted so that no JIT caching happens.
In principle, caching ought not to matter, but another bug is causing the JIT to fail an assertion if a cached eval string is recompiled in a context where variables that were bound are no longer bound.
Differential Revision: D904873
Pushes the sqrt builtin down to codegen for ints and
doubles, which might help on some microbenchmarks, and adds
sqrtsd to the assembler.
Differential Revision: D898146
Inline some of the things into the TC so it can be
specialized on the closure type. Also avoids spilling everything to
the stack to call init (which just pulls it back off and puts it into
the heap), and uses AllocObjFast instead of newInstance. (We can't
quite get the super-fast-path version of AllocObjFast because closures
are extension objects and for now trying to convince it not to use the
m_InstanceCtor is a bit lame---we should probably just generate the
classes as php-level classes at some point so that'll just work.)
Differential Revision: D894569
Jordan DeLong